Open2023/06/05にコメント追加1

supabaseのローカル環境でSQLログを有効化したい

masaoblue

常時有効化はできないけど、一時的にならできたのでとりあえず記録

やりたかったこと

GraphQLのAPIを呼び出したときにどんなSQLが発行されているかを確認したい

TL;DR

コンテナにbashでログイン
/etc/postgresql/postgresql.conf の log_statement を必要な値に書き換え
su - postgres -c "PGDATA=/var/lib/postgresql/data /usr/lib/postgresql/15/bin/pg_ctl reload" で設定再読み込み
- supabase stop で初期化されちゃうので一時的な方法になります

以下は調べたときのメモ

supabaseのpostgresのイメージ

ローカルでsupabase startした状態ｄdocker psすると public.ecr.aws/supabase/postgreというイメージを使っている

とりあえずpostgresコンテナのログを見てみると、ダッシュボードなどからデータをinsertしてもSQLログは出力されなかった。

# project_nameの部分は作業ディレクトリによって異なるので、docker psして確認する
docker logs -f --tail 10 supabase_db_[project_name]

今使っている 15.1.0.73 というバージョンのpostgresql.confの設定を見てみると、log_statementは none に設定されていそうなので、これを変更できればログが出せるはず。(中身をちゃんと追ってないのでこのファイルが直接配置されているかは分からないが)

まずはコンテナに入る

docker exec -it supabase_db_[project_name] bash

ディレクトリを見てみると、/var/lib/postgresql/ あたりにインストールされていた。
で、/var/lib/postgresql/data/postgresql.conf の中身を見てみると、log_statementはコメントアウトされていた。

以下にあるとおり、デフォルトは none なのでログが出ていないと思われる。

ただ、じゃあ↑で見つけたpostgresql.confは何だったんだろう? と思いもう少し探して見たところ、supabase/cli側で起動オプションで cnfig_file=/etc/postgresql/postgresql.conf を指定していた。

こっちのファイルはちゃんと none が指定されていた。

で、対処としてはここをallに書き換える。
viもvimもインストールされていなかったのでとりあえずvimを入れておく

# rootで入ってるのでsudoは不要
apt update
apt install vim

で、vim /etc/postgresql/postgresql.conf して該当部分をallに修正して保存。

なんだけど、普通にpostgresを停止してしまうとコンテナが止まりそうな気がする。
調べてみると pg_ctl reload みたいにすると、プロセスは保持したままでconfの内容を再読み込みしてくれるっぽい。

ただ、普通に実行してみると権限的なところで怒られた。

psコマンドで確認するとpostgresユーザーで起動されているっぽいので、このユーザーを使う。
pg_ctlも普通に打つと見つからなかったので、which pg_ctl して絶対パスで実行してみる。

今度は PGDATA が指定されてないぞって言われた。
なんとなくsuコマンドを実行する時にbashrcとかがちゃんと読まれてないのかなぁ...と思ったけど、以下を実行すると環境変数自体は設定されているようだった。linuxよくわからん

$ su - postgres -c "echo $PGDATA"
/var/lib/postgresql/data

pg_ctlのドキュメントを見るとCLIのオプションとしても渡せそうだったけど、今回はなんとなく変数で渡してみる。

$ su - postgres -c "PGDATA=/var/lib/postgresql/data /usr/lib/postgresql/15/bin/pg_ctl reload"
server signaled

これであとは冒頭のdocker logsでログを表示しながら実際にSQLを発行するとログが出るようになった。
注意点として、この設定は保存されないので、一度 supabase stop してしまうともう一度やり直す必要があるっぽい。ただ今回試したかった GraphQLのAPIを呼び出したときにどんなSQLが発行されているか を一時的に確認する用途としては問題なかったので、これでOKとする。