2025-05-08 release announcement draft

Started by Jonathan S. Katz8 months ago5 messages
#1Jonathan S. Katz
jkatz@postgresql.org
1 attachment(s)

Hi,

Attached is the draft of the release announcement for the 2025-05-08
release. Please review for correctness and omissions.

Please provide feedback no later than 2025-05-08 12:00 UTC.

Thanks,

Jonathan

Attachments:

20250508updaterelease.mdtext/plain; charset=UTF-8; name=20250508updaterelease.mdDownload
#2jian he
jian.universality@gmail.com
In reply to: Jonathan S. Katz (#1)
Re: 2025-05-08 release announcement draft

On Tue, May 6, 2025 at 11:32 AM Jonathan S. Katz <jkatz@postgresql.org> wrote:

Hi,

Attached is the draft of the release announcement for the 2025-05-08
release. Please review for correctness and omissions.

Please provide feedback no later than 2025-05-08 12:00 UTC.

* Prevent failure in
[`INSERT`](https://www.postgresql.org/docs/current/sql-insert.html)
commands when the table has a [`GENERATED`
column](https://www.postgresql.org/docs/current/ddl-generated-columns.html)
of a [domain data type](https://www.postgresql.org/docs/current/domains.html)
and the domain's constraints disallow `NULL` values.
* Fix [`ALTER TABLE .. ADD
COLUMN`](https://www.postgresql.org/docs/current/sql-altertable.html)
to correctly handle the case of a
[domain](https://www.postgresql.org/docs/current/domains.html) type
that has
its own default value and the `DEFAULT` for the column is not set.

same url (https://www.postgresql.org/docs/current/domains.htm) but
with different link text, but here seems
reference the same thing, so it may look a little bit inconsistent?

#3Matthias van de Meent
boekewurm+postgres@gmail.com
In reply to: Jonathan S. Katz (#1)
Re: 2025-05-08 release announcement draft

On Tue, 6 May 2025 at 05:32, Jonathan S. Katz <jkatz@postgresql.org> wrote:

Hi,

Attached is the draft of the release announcement for the 2025-05-08
release. Please review for correctness and omissions.

Please provide feedback no later than 2025-05-08 12:00 UTC.

I think this omits 459e7bf8e (aka 78cb2466f on REL_17_STABLE) which
fixes certain bitmap scans' race condition with VACUUM. I think a line
like the following could be good:

* Fix for potentially incorrect results when bitmap scan nodes without
output columns are run concurrently with VACUUM on the underlying
table.

Kind regards,

Matthias van de Meent

#4Jonathan S. Katz
jkatz@postgresql.org
In reply to: jian he (#2)
Re: 2025-05-08 release announcement draft

On 5/6/25 5:23 AM, jian he wrote:

On Tue, May 6, 2025 at 11:32 AM Jonathan S. Katz <jkatz@postgresql.org> wrote:

Hi,

Attached is the draft of the release announcement for the 2025-05-08
release. Please review for correctness and omissions.

Please provide feedback no later than 2025-05-08 12:00 UTC.

* Prevent failure in
[`INSERT`](https://www.postgresql.org/docs/current/sql-insert.html)
commands when the table has a [`GENERATED`
column](https://www.postgresql.org/docs/current/ddl-generated-columns.html)
of a [domain data type](https://www.postgresql.org/docs/current/domains.html)
and the domain's constraints disallow `NULL` values.
* Fix [`ALTER TABLE .. ADD
COLUMN`](https://www.postgresql.org/docs/current/sql-altertable.html)
to correctly handle the case of a
[domain](https://www.postgresql.org/docs/current/domains.html) type
that has
its own default value and the `DEFAULT` for the column is not set.

same url (https://www.postgresql.org/docs/current/domains.htm) but
with different link text, but here seems
reference the same thing, so it may look a little bit inconsistent?

I don't think in this case that this is particularly an issue, but I
went ahead and modified it to be consistent ("domain type" in both cases).

Thanks,

Jonathan

#5Jonathan S. Katz
jkatz@postgresql.org
In reply to: Matthias van de Meent (#3)
Re: 2025-05-08 release announcement draft

On 5/6/25 8:29 AM, Matthias van de Meent wrote:

On Tue, 6 May 2025 at 05:32, Jonathan S. Katz <jkatz@postgresql.org> wrote:

Hi,

Attached is the draft of the release announcement for the 2025-05-08
release. Please review for correctness and omissions.

Please provide feedback no later than 2025-05-08 12:00 UTC.

I think this omits 459e7bf8e (aka 78cb2466f on REL_17_STABLE) which
fixes certain bitmap scans' race condition with VACUUM. I think a line
like the following could be good:

* Fix for potentially incorrect results when bitmap scan nodes without
output columns are run concurrently with VACUUM on the underlying
table.

Added with some wordsmithing:

* Fix for potentially returning incorrect results when a bitmap scan
without output columns is executed while vacuum is also running on the
same table.

Jonathan