From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Daniel Bauman <danielbaniel(at)gmail(dot)com> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Doc update proposal for the note on log_statement in the runtime config for logging page |
Date: | 2025-07-29 15:46:27 |
Message-ID: | CAKFQuwb9DdOHPpzOZd17ipVNiAEeS+rxMcD=EiJo=HDDSdrW4g@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Monday, July 28, 2025, Daniel Bauman <danielbaniel(at)gmail(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Jehan-Guillaume de Rorthais | 2025-07-29 15:48:52 | Re: [(known) BUG] DELETE/UPDATE more than one row in partitioned foreign table |
Previous Message | Tom Lane | 2025-07-29 15:40:11 | Re: split func.sgml to separated individual sgml files |