Thread: 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. On behalf of the PG18 RMT, - Heikki
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] 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: https://www.postgresql.org/message-id/CAEze2Wh9JjLKdN3dHPF%3DNejzf%3D9fDfcYAqM6j1xHJqOFALfDgQ%40mail.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