On Fri, May 8, 2026 at 4:39 AM Daniel Bauman <danielbaniel@gmail.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_statementparameter 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
possibleto 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
collectoris designed to never lose messages." is appropriate. This statement reads like a strong guarantee to me. I
thinkit could be helpful to phrase it in a way that makes it clearer that the logging collector will delay the
applicationif 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
collectoris 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
