On Tue, Jul 28, 2020 at 10:07 AM torikoshia <torikos...@oss.nttdata.com> wrote: > > Thanks for updating! > I tested the patch setting log_statement = 'all', but %Q in > log_line_prefix > was always 0 even when pg_stat_statements.queryid and > pg_stat_activity.queryid are not 0. > > Is this an intentional behavior? > >[...]
Thanks for the tests! That's indeed an expected behavior (although I wasn't aware of it), which isn't documented in this patch (I'll fix it). The reason for that is that log_statements is done right after parsing the query: /* * Do basic parsing of the query or queries (this should be safe even if * we are in aborted transaction state!) */ parsetree_list = pg_parse_query(query_string); /* Log immediately if dictated by log_statement */ if (check_log_statement(parsetree_list)) { ereport(LOG, (errmsg("statement: %s", query_string), errhidestmt(true), errdetail_execute(parsetree_list))); was_logged = true; } As parse analysis is not yet done, no queryid can be computed at that point, so we always print 0. That's a limitation that can't be removed without changing the semantics of log_statements, so we'll probably have to live with it. > And here is a minor typo. > optionnally -> optionally > > > > 753 + /* query identifier, optionnally computed using > > post_parse_analyze_hook */ Thanks, I fixed it locally!