On Wed, 2021-05-12 at 18:03 +0530, Bharath Rupireddy wrote: > On Wed, May 12, 2021 at 4:54 PM torikoshia <torikos...@oss.nttdata.com> wrote: > > During the discussion about memory contexts dumping[1], there > > was a comment that exposing not only memory contexts but also > > query plans and untruncated query string would be useful. > > > > postgres=# SELECT * FROM pg_log_current_plan(2155192); > > pg_log_current_plan > > --------------------- > > t > > (1 row) > > > > $ tail -f data/log/postgresql-2021-05-12.log > > > > 2021-05-12 17:37:19.481 JST [2155192] LOG: logging the plan of > > running query on PID 2155192 > > Query Text: SELECT a.filler FROM pgbench_accounts a JOIN > > pgbench_accounts b ON a.aid = b.aid; > > Merge Join (cost=0.85..83357.85 rows=1000000 width=85) > > Merge Cond: (a.aid = b.aid) > > -> Index Scan using pgbench_accounts_pkey on > > pgbench_accounts a (cost=0.42..42377.43 rows=1000000 width=89) > > -> Index Only Scan using pgbench_accounts_pkey on > > pgbench_accounts b (cost=0.42..25980.42 rows=1000000 width=4)
I love the idea, but I didn't look at the patch. > Since it also shows up the full query text and the plan > in the server log as plain text, there are chances that the sensitive > information might be logged into the server log which is a risky thing > from security standpoint. I think that is irrelevant. A superuser can already set "log_statement = 'all'" to get this. There is no protection from superusers, and it is pointless to require that. Yours, Laurenz Albe
