Re: PG 18 release notes draft committed

On Wed, May 28, 2025 at 08:07:20PM -0400, Melanie Plageman wrote:
> For the item:
>
> "Increase the logging granularity of server variable log_connections"
>
> I noticed that you cite the commit 9219093cab2 that actually does
> modularize the GUC but you also cite a separate following commit
> 18cd15e706ac which adds a new option that logs the duration of various
> parts of connection establishment and backend setup. That is, it is a
> separate feature.
>
> 9219093cab2 made it so we could add options and have them be
> individually enabled or disabled in logging. But 18cd15e706ac is only
> related insomuch as we probably wouldn't have added it if
> log_connections had been just a boolean and it was enabled by default.
>
> Anyway, it might be worth separately calling out that now you can
> configure log_connections to log the durations of various parts of
> connection establishment and backend setup -- which is a distinct
> feature from modularization.

Yes, I can now see it is two items so I have split it into two in the
attached, applied patch. In a separate commit I adjusted the docs for
log_connections to more clearly explain the new "setup_durations"
output.

> For the item:
>
> "Add an asynchronous I/O subsystem"
>
> I notice we don't call out any of the operations where users could
> expect to see asynchronous IO be used. Some were enabled in 17 (like
> sequential scans, analyze, and pg_prewarm), but most of the read
> stream users went in this release:
>
> d9c7911e1a5, 043799fa08c, e215166c9c8, 69273b818b1, c5c239e26e3,
> 2b73a8cd33b, 9256822608f, c3e775e608f, 8720a15e9ab12, 65c310b310a
>
> I have had users ask me already which operations they can expect to
> use asynchronous I/O. The most commonly encountered AIO operations are
> probably be vacuum, bitmap heap scan, and sequential scans, but it
> might be worth having a list somewhere of what uses AIO. I expect
> we'll get the question quite often.

Yes, I knew I needed more detail on this. I have added text in this
commit to try to improve that.

> And finally, for the item:
>
> "Allow specification of the fixed number of dead tuples that will
> trigger an autovacuum"
>
> We also added a kind of corollary for insert-triggered vacuums in
> 06eae9e6218ab2a which attempts to deal with a similar problem of big
> tables not being autovacuumed enough but for insert-mostly tables.
> Perhaps because there is no exposed configuration it is not worth
> mentioning, but I thought I would bring it up since their purposes are
> related.

I studied this and I can't figure out how to clearly explain it in a
useful way. I am now thinking it is more of a bug or behavior fix or
that would not be usually mentioned.

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com

Do not let urgent matters crowd out time for investment in the future.