Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view? - Mailing list pgsql-hackers

On Tue, Jul 28, 2020 at 10:07 AM torikoshia <torikoshia@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!