On Fri, May 8, 2026 at 4:39 AM Daniel Bauman <[email protected]> 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
