2026-05-14 release announcement draft

On Sun, May 10, 2026 at 9:44 PM Jonathan S. Katz <jkatz@postgresql.org> wrote:

Hi,

I've attached a draft of the 2026-05-14 release announcement. Please
provide feedback on corrections, notable omissions, typos, etc. no later
than 2026-05-14 12:00 UTC (though preferable earlier sooner! :)

Generally LGTM, some minor comments / thoughts below...

* I thought this one "Improve the planner's ability to apply partition
pruning to more cases." was worded more like a feature enhancement
rather than a fix of some kind, but I didn't see the corresponding
commit, so not sure what improvement to suggest.

* I'd probably rewrite this one:
< Ensure that changes to the free space maps for tables are persisted
during recovery. This could have performance ramifications on a
standby server after promotion.

Ensure that tables free space map changes are persisted during recovery. This could have performance ramifications on a standby server after promotion.

(I'm tempted to drop the word "tables" from my version as well, it
seems like it mostly just gets in the way for both versions).

Also, there was a sizeable number of security related fixes committed
today which are not included here; I presume you are working on a v2
which includes some information on those?

Robert Treat
https://xzilla.net

On 5/11/26 4:52 PM, Robert Treat wrote:

On Sun, May 10, 2026 at 9:44 PM Jonathan S. Katz <jkatz@postgresql.org> wrote:

Hi,

I've attached a draft of the 2026-05-14 release announcement. Please
provide feedback on corrections, notable omissions, typos, etc. no later
than 2026-05-14 12:00 UTC (though preferable earlier sooner! :)

Generally LGTM, some minor comments / thoughts below...

* I thought this one "Improve the planner's ability to apply partition
pruning to more cases." was worded more like a feature enhancement
rather than a fix of some kind, but I didn't see the corresponding
commit, so not sure what improvement to suggest.

It was this one:

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=8e8b2bef7

* I'd probably rewrite this one:

I went with:

Ensure that free space map changes are persisted during recovery.
This could have performance ramifications on a standby server after

promotion.

Thanks,

Jonathan