Re: Doc update proposal for the note on log_statement in the runtime config for logging page

David G. Johnston <david.g.johnston@gmail.com>

From: "David G. Johnston" <david.g.johnston@gmail.com>
To: Daniel Bauman <danielbaniel@gmail.com>
Cc: Bruce Momjian <bruce@momjian.us>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Date: 2025-07-29T15:46:27Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Avoid regression in the size of XML input that we will accept.

On Monday, July 28, 2025, Daniel Bauman <danielbaniel@gmail.com> wrote:

> The doc fragment you shared is explaining to customers that basic syntax
> checks are done before postgres gets to logging the transaction.
> I don't think that is the same as clearly explaining to users statement
> logging happens before execution.
>

He quoted the wrong sentence.  This is the definitive one:

For clients using extended query protocol, logging occurs when an Execute
message is received, and values of the Bind parameters are included (with
any embedded single-quote marks doubled).
David J.




> At least for me, as a user and reader of the docs but not someone familiar
> with the code, the docs didn't make it clear to me how statement logging
> corresponded to query execution.
>
> Do you think there's room to document something like
> "Statements are logged before they are executed. It's not guaranteed that
> logged statements have been successfully executed."
> I'd be happy to submit and iterate on a pull request if you do.
>

The first sentence maybe.  If you find this important enough to submit a
patch using our submission process go ahead.  On that note, please observe
that we in-line reply and trim here, not top-post.


>
> I'd also like to understand what happens if there are errors writing the
> log - like the disk where the log directory is configured being full.
> My understanding is the following. ereport (https://github.com/postgres/
> postgres/blob/71c0921b649d7a800eb2d6f93539890eaa14d979/src/include/utils/
> elog.h#L163) will end up calling errfinish and errfinish will call
> EmitErrorReport (https://github.com/postgres/postgres/blob/master/src/
> backend/utils/error/elog.c#L543) which will call
> send_message_to_server_log (https://github.com/postgres/postgres/blob/
> 71c0921b649d7a800eb2d6f93539890eaa14d979/src/backend/utils/
> error/elog.c#L1733) and that will call write_syslogger_file (
> https://github.com/postgres/postgres/blob/71c0921b649d7a800eb2d6f9353989
> 0eaa14d979/src/backend/utils/error/elog.c#L3443C2-L3443C16).
> write_syslogger_file looks like it handles errors by logging to stderr but
> not raising an error condition that would cancel the transaction (
> https://github.com/postgres/postgres/blob/71c0921b649d7a800eb2d6f9353989
> 0eaa14d979/src/backend/postmaster/syslogger.c#L1126)
>
> Do I understand correctly or am I on the wrong codepath?
>

That sounds right.  It’s deemed overly harsh to crash the server just
because some logging doesn’t happen.

David J.