On Wed, 2021-05-12 at 18:03 +0530, Bharath Rupireddy wrote:
> On Wed, May 12, 2021 at 4:54 PM torikoshia <torikoshia@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