Обсуждение: 2025-05-08 release announcement draft

Поиск
Список
Период
Сортировка

2025-05-08 release announcement draft

От
"Jonathan S. Katz"
Дата:
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

Вложения

Re: 2025-05-08 release announcement draft

От
jian he
Дата:
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?



Re: 2025-05-08 release announcement draft

От
Matthias van de Meent
Дата:
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



Re: 2025-05-08 release announcement draft

От
"Jonathan S. Katz"
Дата:
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

Вложения

Re: 2025-05-08 release announcement draft

От
"Jonathan S. Katz"
Дата:
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

Вложения