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

On Fri, May 8, 2026 at 4:39 AM Daniel Bauman <danielbaniel(at)gmail(dot)com> wrote:
>
> I have attached a patch making the change in the note under the logging_collector (https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOGGING-COLLECTOR) instead of on the log_statement parameter as I had initially suggested.
>

I agree that's better place.

> I'm open to any feedback. I've tried to keep the details vague while calling out for non-technical users that it is possible to have transactions complete without associated logs making it to disk.
>
> Another change I'd like to know your thoughts on is whether changing the existing wording that says "The logging collector is designed to never lose messages." is appropriate. This statement reads like a strong guarantee to me. I think it could be helpful to phrase it in a way that makes it clearer that the logging collector will delay the application if it can't keep up with logging volume without saying something as strong as "never lose messages".
> If you think it is a good idea I can add a change in the patch to reword it to something weaker like "The logging collector is designed to avoid losing messages."

Since the point of this description seems that the logging collector does not
have something like well-known syslog's rate-limiting behavior (i.e., dropping
messages under very high log volume), I'd prefer wording like:

The logging collector is designed to avoid dropping messages even under
very high log volume.

Thought?

+ The logging collector writes to disk asynchronously. The server
+ losing power or errors when writing to the log file
+ can result in messages not being persisted.

"writes to disk asynchronously" feels a bit ambiguous to me.
How about something like:

The logging collector does not guarantee that log messages have
reached durable storage.
A system crash, power loss, or an error while writing the log file
can still result in messages
being lost.

Regards,

--
Fujii Masao