PostgreSQLの裏側を学びたい(Step3:バックエンドプロセスを学ぶ)

はじめに

前回までの続きです。バックエンドプロセスを学ぶ。
今回もChatGPTに教えてもらっているので、解説までは正しくない内容を記載している可能性があります😀

バックエンドプロセス（Backend Process）を理解する

Postmaster（マスターサーバプロセス）は、サーバ全体の司令塔でした。
では実際に SQLを実行しているのは誰か？
それが「バックエンドプロセス（Backend Process）」です。

🧠 バックエンドプロセスとは？

• クライアント（psql やアプリ）が PostgreSQL に接続したときに、
  Postmaster が fork() して生成する子プロセス です。
• 1つの接続に対して1つずつ作られます（＝1接続1プロセスモデル）。

つまり：
クライアント1つ → バックエンドプロセス1つ
クライアント5つ → バックエンドプロセス5つ

🧩 バックエンドプロセスの仕事の流れ

1. クライアントから SQL を受け取る
2. SQL を構文解析（パース）する
3. 実行計画を立てる（プランニング）
4. 実行して結果を返す
5. クライアントが切断したら終了

→僕らが普段お世話になっているのはバックエンドプロセスなんですね！

Hands-on

実際に手を動かしながら理解を深めていきます！！
ここでは、クライアントを接続前後でプロセスができているかをみていきます。

クライアント実行前

~/develop/postgresql_study  (main)$ docker compose exec -it db bash
root@3f83029523db:/# ps aux | grep '[p]ostgres'
postgres     1  0.0  0.1 217732 27664 ?        Ss   07:10   0:00 postgres
postgres    28  0.0  0.0 217864  8556 ?        Ss   07:10   0:00 postgres: checkpointer 
postgres    29  0.0  0.0 217888  7376 ?        Ss   07:10   0:00 postgres: background writer 
postgres    31  0.0  0.0 217732 10304 ?        Ss   07:10   0:00 postgres: walwriter 
postgres    32  0.0  0.0 219328  8128 ?        Ss   07:10   0:00 postgres: autovacuum launcher 
postgres    33  0.0  0.0 219312  8492 ?        Ss   07:10   0:00 postgres: logical replication launcher 
postgres   216  0.0  0.0 219056  7160 ?        Ss   07:45   0:00 postgres: autovacuum worker 

実際にpostgresに接続します

~/develop/postgresql_study  (main)$ PGPASSWORD=password psql -h 127.0.0.1 -U user -d mydatabase
psql (14.19 (Homebrew), server 16.10 (Debian 16.10-1.pgdg13+1))
WARNING: psql major version 14, server major version 16.
         Some psql features might not work.
Type "help" for help.

クライアント実行後

root@3f83029523db:/# ps aux | grep '[p]ostgres'
postgres     1  0.0  0.1 217732 27664 ?        Ss   07:10   0:00 postgres
postgres    28  0.0  0.0 217864  8556 ?        Ss   07:10   0:00 postgres: checkpointer 
postgres    29  0.0  0.0 217888  7376 ?        Ss   07:10   0:00 postgres: background writer 
postgres    31  0.0  0.0 217732 10304 ?        Ss   07:10   0:00 postgres: walwriter 
postgres    32  0.0  0.0 219328  8128 ?        Ss   07:10   0:00 postgres: autovacuum launcher 
postgres    33  0.0  0.0 219312  8492 ?        Ss   07:10   0:00 postgres: logical replication launcher 
postgres   217  0.0  0.0 219744 13324 ?        Ss   07:45   0:00 postgres: user mydatabase 172.27.0.1(63100) idle
root@3f83029523db:/# 

→確かに1個増えていますね。
postgres 217 0.0 0.0 219744 13324 ? Ss 07:45 0:00 postgres: user mydatabase 172.27.0.1(63100) idle
これがバックエンドプロセスなんですね！

バックエンドプロセスの変化を確認する。

SQLを実行した時にどんな風になるかをみていきましょう！！

10秒待機のSQL

mydatabase=#  SELECT pg_sleep(10);
 pg_sleep 
----------
 
(1 row)

→10秒待機するSELECT文を発行します

## 10秒待機SQL実行前
root@3f83029523db:/# ps -ef | grep "postgres:" | grep -vE "checkpointer|writer|wal|auto|stats|logical|grep"
postgres   217     1  0 07:45 ?        00:00:00 postgres: user mydatabase 172.27.0.1(63100) idle

## 10秒待機SQL実行中
root@3f83029523db:/# ps -ef | grep "postgres:" | grep -vE "checkpointer|writer|wal|auto|stats|logical|grep"
postgres   217     1  0 07:45 ?        00:00:00 postgres: user mydatabase 172.27.0.1(63100) SELECT

## 10秒待機SQL実行後
root@3f83029523db:/# ps -ef | grep "postgres:" | grep -vE "checkpointer|writer|wal|auto|stats|logical|grep"
postgres   217     1  0 07:45 ?        00:00:00 postgres: user mydatabase 172.27.0.1(63100) idle

→なるほど待機されていますね。

気になること

10秒待機後に後ろからSQLの依頼があったとする。それって10秒後に実行されるのか？ちょっとわからなかったので、聞いてみた。
1コネクション = 1バックエンドプロセスのため、コネクションに空きがあればすぐ実行。空きがなければ待機するようです。なるほどなぁ。
次回はコネクションプールに関して学んでいこうと思います！！コネクションプールは聞いてはいたけど、実際に見て学ぶまではしていなかったので。