Horton

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

Daniel Bauman <danielbaniel@gmail.com>

View thread
From: Daniel Bauman <danielbaniel@gmail.com>
To: Fujii Masao <masao.fujii@gmail.com>
Cc: "David G. Johnston" <david.g.johnston@gmail.com>, Bruce Momjian <bruce@momjian.us>, pgsql-hackers@lists.postgresql.org
Date: 2026-05-08T15:23:56Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Avoid regression in the size of XML input that we will accept.

Thanks Fujii, I like both of those suggestions. I’ll incorporate them into
a v2.

On Thu, May 7, 2026 at 5:24 PM Fujii Masao <masao.fujii@gmail.com> wrote:

> 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_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
>