Everyone into the Pool covered five PostgreSQL connection poolers and waved at two more on the way out. That left a fair number of people standing at the edge with a towel: anyone running on Azure or Google Cloud, anyone who wants PgBouncer’s job done on more than one core, and anyone whose application already has a pool and would

The comment at the top of async.c says that notify_buffers “can be varied without affecting anything but performance.” I went looking for the performance. The most I found was 10% of throughput, and I had to send more than 100MB of notifications a second to find it.

This is one of the seven SLRU cache sizes that PostgreSQL 17

pgvector 0.8.7 fixes CVE-2026-103484: a database user who can create an IVFFlat index can write out of bounds in the backend, which can lead to arbitrary code execution. Every version through 0.8.6 is affected. Upgrade.

That part is simple. Two other parts are not: who can actually reach the bug, and what “upgraded” means for a backend that

multixact_offset_buffers defaults to 16 buffers, and through PostgreSQL 18, 16 buffers hold the offsets of 32,768 multixacts. multixact_member_buffers defaults to 32, which holds 52,352 members. Whether those numbers are generous or absurd depends on one thing: how many multixacts your system creates while its longest row-locking transaction is open.

These are two of the seven SLRU cache sizes that

min_wal_size has a better description in pg_settings than it has in the documentation: “Sets the minimum size to shrink the WAL to.” That is all it does. It is a floor under how far pg_wal is allowed to shrink, and it keeps no WAL that anything could read, though the name invites reading it as a retention setting. Here is

Both names say “minimum,” and both parameters do set one: a scan the planner expects to read less than min_parallel_table_scan_size of table (default 8MB) or less than min_parallel_index_scan_size of index (default 512kB) is not considered for a parallel plan. That is the documented half. The other half is that each value is also the bottom rung of the

PgBouncer 1.26.0 came out on September 23 and fixes three CVEs. Two of them can be triggered by anyone who can open a TCP connection to the listener. They need no password and no valid username. If PgBouncer sits anywhere a hostile packet can reach it, upgrade before you finish reading this.

Now that you’ve started the upgrade, here

md5_password_warnings is the off switch for a deprecation notice. PostgreSQL 18 deprecated MD5 password hashes, started emitting a WARNING whenever one is stored, and shipped this parameter in the same commit so that you could make the warning stop. It is a boolean, the default is on, and the context is user: any role can turn it off

max_wal_size is not a maximum, and it is not the size of anything you can du. It is a checkpoint trigger denominated in bytes: once the WAL written since the last checkpoint started reaches a fixed fraction of this value (the fraction is below, and it is not 1), the next one starts, whether or not checkpoint_timeout has come