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

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Daniel Bauman <danielbaniel(at)gmail(dot)com>
Cc: 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-28 18:37:59
Message-ID: aIfDhzCSfy5akvra@momjian.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jul 25, 2025 at 03:24:48PM -0700, Daniel Bauman wrote:
> Hey pgsql hackers
> This is my first email to this list. I'm reaching out about a possible doc
> update for the log_statement parameter.
> Here's the current doc - https://www.postgresql.org/docs/current/
> runtime-config-logging.html
> The doc already has a Note bubble for the log_statement parameter with some
> important callouts.
>
> I am proposing adding something there to call out that there is no guarantee
> provided that all committed statements in the DB will be logged. The logging to
> the log file is not part of PGs ACID compliant DB engine but instead a separate
> best-effort system. This might be obvious to some people but I don't think it
> is for everyone.
>
> In many cases people will use these logs for security, legal or compliance
> reasons and I think it's relevant to users to make the consistency guarantees
> explicit and clear.
>
> Please let me know what you think and also if you think there's a different
> place where this notification would be better placed. Maybe it already exists
> somewhere else.
>
> This would be very similar to the documentation that MySQL have over here - 
> https://dev.mysql.com/doc/refman/8.4/en/audit-log-logging-configuration.html
> "Regardless of strategy, logging occurs on a best-effort basis, with no
> guarantee of consistency."
>
> I believe the same applies to the PGAudit extension but I'm starting out here.

Why do you think log_statement is best effort?

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com

Do not let urgent matters crowd out time for investment in the future.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2025-07-28 18:42:11 Re: Better HINT message for "unexpected data beyond EOF"
Previous Message Nathan Bossart 2025-07-28 18:34:11 Re: vacuumdb changes for stats import/export