Thread: 2022-06-16 release announcement draft

Hi,

Please see the attached draft of the release announcement for the 
2022-06-16 release.

Please review for technical accuracy and omissions. If you have 
feedback. please provide it no later than Thu, June 16, 2022 0:00 AoE[1].

Thanks,

Jonathan

[1] https://en.wikipedia.org/wiki/Anywhere_on_Earth

"Jonathan S. Katz" <jkatz@postgresql.org> writes:
> Please review for technical accuracy and omissions.

A few minor thoughts:

> The PostgreSQL Global Development Group has released PostgreSQL 14.4 to fix an
> issue that could cause silent data corruption when using the
> [`CREATE INDEX CONCURRENTLY`](https://www.postgresql.org/docs/current/sql-createindex.html)
> and [`REINDEX CONCURRENTLY`](https://www.postgresql.org/docs/current/sql-reindex.html)
> commands.

Maybe s/and/or/ ?

> PostgreSQL 14.4 fixes an issue with the
> [`CREATE INDEX CONCURRENTLY`](https://www.postgresql.org/docs/current/sql-createindex.html)
> and [`REINDEX CONCURRENTLY`](https://www.postgresql.org/docs/current/sql-reindex.html)
> that could cause silent data corruption of indexes.

Either leave out "the" or add "commands".  That is, "the FOO and BAR
commands" reads fine, "the FOO and BAR" less so.  Also, I'm inclined
to be a bit more specific and say that the problem is missing index
entries, so maybe like "... fixes an issue that could cause the [CIC]
and [RIC] commands to omit index entries for some rows".

> Once you upgrade your system to PostgreSQL 14.4, you can fix any silent data
> corruption using `REINDEX CONCURRENTLY`.

Perhaps it is also worth mentioning that you can use REINDEX without
CONCURRENTLY, even before upgrading.

> * Report implicitly-created operator families (`CREATE OPERATOR CLASS`) to event
> triggers.

Maybe "(generated by `CREATE OPERATOR CLASS`)"?  As-is, the parenthetical
comment looks more like a mistake than anything else.

The rest looks good.

            regards, tom lane

On 6/13/22 1:38 PM, Tom Lane wrote:
> "Jonathan S. Katz" <jkatz@postgresql.org> writes:
>> Please review for technical accuracy and omissions.
> 
> A few minor thoughts:
> 
>> The PostgreSQL Global Development Group has released PostgreSQL 14.4 to fix an
>> issue that could cause silent data corruption when using the
>> [`CREATE INDEX CONCURRENTLY`](https://www.postgresql.org/docs/current/sql-createindex.html)
>> and [`REINDEX CONCURRENTLY`](https://www.postgresql.org/docs/current/sql-reindex.html)
>> commands.
> 
> Maybe s/and/or/ ?

Fixed.

>> PostgreSQL 14.4 fixes an issue with the
>> [`CREATE INDEX CONCURRENTLY`](https://www.postgresql.org/docs/current/sql-createindex.html)
>> and [`REINDEX CONCURRENTLY`](https://www.postgresql.org/docs/current/sql-reindex.html)
>> that could cause silent data corruption of indexes.
> 
> Either leave out "the" or add "commands".  That is, "the FOO and BAR
> commands" reads fine, "the FOO and BAR" less so. 

Yeah, that was likely an edit-o. Fixed.

> Also, I'm inclined
> to be a bit more specific and say that the problem is missing index
> entries, so maybe like "... fixes an issue that could cause the [CIC]
> and [RIC] commands to omit index entries for some rows".

Agreed. Edited in attached.

>> Once you upgrade your system to PostgreSQL 14.4, you can fix any silent data
>> corruption using `REINDEX CONCURRENTLY`.
> 
> Perhaps it is also worth mentioning that you can use REINDEX without
> CONCURRENTLY, even before upgrading.

I'm hesitant on giving too many options. We did put out the "warning" 
announcement providing this as an option. I do think that folks who are 
running CIC/RIC are sensitive to locking, and a plain old "REINDEX" may 
be viable except in an emergency.

>> * Report implicitly-created operator families (`CREATE OPERATOR CLASS`) to event
>> triggers.
> 
> Maybe "(generated by `CREATE OPERATOR CLASS`)"?  As-is, the parenthetical
> comment looks more like a mistake than anything else.

Fixed.

> The rest looks good.

Thanks for the review! Next version attached.

Jonathan

On Mon, Jun 13, 2022 at 6:15 PM Jonathan S. Katz <jkatz@postgresql.org> wrote:
> > Perhaps it is also worth mentioning that you can use REINDEX without
> > CONCURRENTLY, even before upgrading.
>
> I'm hesitant on giving too many options. We did put out the "warning"
> announcement providing this as an option. I do think that folks who are
> running CIC/RIC are sensitive to locking, and a plain old "REINDEX" may
> be viable except in an emergency.

The locking implications for plain REINDEX are surprising IMV -- and
so I suggest sticking with what you have here.

In many cases using plain REINDEX is not meaningfully different to
taking a full AccessExclusiveLock on the table (we only acquire an AEL
on the index, but in practice that can be a distinction without a
difference). We at least went some way towards making the situation
with REINDEX locking clearer in a doc patch that recently became
commit 8ac700ac.

--
Peter Geoghegan