PostgreSQL 18 Release Management Team & Feature Freeze

Hi,

We are pleased to announce the Release Management Team (RMT) (cc'd) for
the PostgreSQL 18 release:

- Tomas Vondra
- Nathan Bossart
- Heikki Linnakangas

You can find information about the responsibilities of the RMT here:
https://wiki.postgresql.org/wiki/Release_Management_Team

We have now entered the feature freeze period. That means that no new
features will committed for v18 anymore. I ask everyone to focus on
testing the new features that got in, documentation, and fixes for old
and new bugs.

You can track open items for the PostgreSQL 18 release here:
https://wiki.postgresql.org/wiki/PostgreSQL_18_Open_Items

Please let us know if you have any questions.

Let me be the first author this year who asks to squeeze his patch in
after feature freeze :D

Do you think that it's worth merging SLRU refactoring into PG18, or is
it considered a feature? [1]https://commitfest.postgresql.org/patch/5250/ This is arguably not the top priority and
we could wait for another year but merging it now doesn't seem to be
too much of a burden either.

[1]: https://commitfest.postgresql.org/patch/5250/

--
Best regards,
Aleksander Alekseev

On 10/04/2025 14:57, Aleksander Alekseev wrote:

Let me be the first author this year who asks to squeeze his patch in
after feature freeze :D

:-)

Do you think that it's worth merging SLRU refactoring into PG18, or is
it considered a feature? [1] This is arguably not the top priority and
we could wait for another year but merging it now doesn't seem to be
too much of a burden either.

[1]: https://commitfest.postgresql.org/patch/5250/

I would consider that a feature, too late for v18. There's not
particular benefit in getting it into v18 vs later.

--
Heikki Linnakangas
Neon (https://neon.tech)

Hi,

Do you think that it's worth merging SLRU refactoring into PG18, or is
it considered a feature? [1] This is arguably not the top priority and
we could wait for another year but merging it now doesn't seem to be
too much of a burden either.

[1]: https://commitfest.postgresql.org/patch/5250/

I would consider that a feature, too late for v18. There's not
particular benefit in getting it into v18 vs later.

It was worth a try :) Good to know then, I will move the CF entry to
the next commitfest. Thanks!

--
Best regards,
Aleksander Alekseev

On 10/04/2025 14:57, Aleksander Alekseev wrote:

Let me be the first author this year who asks to squeeze his patch in
after feature freeze :D

On that note, I spoke with Matthias off-list, and he pointed out this patch:

/messages/by-id/CAEze2Wh9JjLKdN3dHPF=Nejzf=9fDfcYAqM6j1xHJqOFALfDgQ@mail.gmail.com

It makes changes to the table AM API, to fix an existing bug. If that's
how we want to fix it, now's the last chance to make table AM API
changes for v18.

An argument against doing it now is that we need to come up with a
back-patchable fix anyway. That'll probably be more hacky, but there's
little harm in doing it the the same hacky way for one more release.

(I have not looked at the patches, so don't know if there are other issues)

--
Heikki Linnakangas
Neon (https://neon.tech)

On Thu, Apr 10, 2025 at 03:11:00PM +0300, Heikki Linnakangas wrote:

On 10/04/2025 14:57, Aleksander Alekseev wrote:

Do you think that it's worth merging SLRU refactoring into PG18, or is
it considered a feature? [1] This is arguably not the top priority and
we could wait for another year but merging it now doesn't seem to be
too much of a burden either.

I would consider that a feature, too late for v18. There's not particular
benefit in getting it into v18 vs later.

+1

--
nathan