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

From: Daniel Bauman <danielbaniel(at)gmail(dot)com>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, 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-30 16:27:39
Message-ID: CAMtj0_ZB6VB9wjp2f=yow=b8kd7fQN3V-g9swAPRDcHFKn9AvQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jul 29, 2025 at 11:46 AM David G. Johnston <
david(dot)g(dot)johnston(at)gmail(dot)com> wrote:

>
>
> On Tue, Jul 29, 2025, 10:07 Daniel Bauman <danielbaniel(at)gmail(dot)com> wrote:
>
>>
>> The tradeoff to ignore errors and not fsync every log absolutely makes
>> sense to me. It's just something it would be beneficial for users to be
>> aware of. Particularly those concerned with auditing.
>>
>
> The main question is where to put such info. The config settings section
> seems like an odd place to find that.
>
> David J.
>
>
From looking through the docs I think that adding to the note under the
log_statement is an appropriate place.
It already calls out other statement logging details like the fact that
statements are only logged after basic validation and that statements can
contain sensitive information.
I think adding a statement much like the MySQL wording is correct (
"Statement logging occurs on a best-effort basis, with no guarantee of
consistency." is descriptive without getting into unnecessary details for
the user about fsync, transactions and error handling. That could
separately be discussed in the code comments for developers.
I think the best-effort wording is justified and it probably is for most DB
engines. Error logging is not transactional, it's not part of the WAL. Even
though statement logging happens before the tx is executed it isn't fsynced
for each statement and write errors don't prevent transactions from being
processed.

What do you think?

-Daniel

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jacob Champion 2025-07-30 17:17:25 Re: restore_command return code behaviour
Previous Message Jacob Champion 2025-07-30 16:13:06 Re: Support getrandom() for pg_strong_random() source