Re: Doc update proposal for the note on log_statement in the runtime config for logging page
Daniel Bauman <danielbaniel@gmail.com>
From: Daniel Bauman <danielbaniel@gmail.com>
To: "David G. Johnston" <david.g.johnston@gmail.com>
Cc: Bruce Momjian <bruce@momjian.us>, pgsql-hackers@lists.postgresql.org
Date: 2026-05-07T19:39:06Z
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 →
-
Avoid regression in the size of XML input that we will accept.
- 71c0921b649d 19 (unreleased) cited
Attachments
- v1-0001-Update-docs-for-log_collector-about-error-cases.patch (application/octet-stream) patch v1-0001
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'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." Thanks for your time, -Daniel p.s. I started this thread in the hackers list but this is a doc change. Let me know if I should replace hackers with the doc list in my next reply.