2021-02-11 release announcement draft

On Mon, Feb 08, 2021 at 05:40:41PM -0500, Jonathan S. Katz wrote:

This update also fixes over 80 bugs that were reported in the last several
months. Some of these issues only affect version 13, but may also apply to other
supported versions.

Did you want s/may/many/?

* Fix an issue with GiST indexes where concurrent insertions could lead to a
corrupt index with entries placed in the wrong pages. You should `REINDEX` any
affected GiST indexes.

For what it's worth, there's little way for a user to confirm whether an index
is affected. (If you've never had more than one connection changing the table
at a time, the table's indexes would be unaffected.)

* Fix `CREATE INDEX CONCURRENTLY` to ensure rows from concurrent prepared
transactions are included in the index.

Consider adding a sentence like "Installations that have enabled prepared
transactions should `REINDEX` any concurrently-built indexes." The release
notes say:

+      In installations that have enabled prepared transactions
+      (<varname>max_prepared_transactions</varname> &gt; 0),
+      it's recommended to reindex any concurrently-built indexes in
+      case this problem occurred when they were built.

* Fix a failure when a PL/pgSQL procedure used `CALL` on another procedure that
has `OUT` parameters did not call execute a `COMMIT` or `ROLLBACK`.

The release notes say the failure happened when the callee _did_ execute a
COMMIT or ROLLBACK:

+     <para>
+      A <command>CALL</command> in a PL/pgSQL procedure, to another
+      procedure that has OUT parameters, would fail if the called
+      procedure did a <command>COMMIT</command>
+      or <command>ROLLBACK</command>.
+     </para>

For more details, please see the
[release notes](https://www.postgresql.org/docs/current/release.html).

I recommend pointing this to https://www.postgresql.org/docs/release/, since
the above link now contains only v13 notes.

On 02/08/2021 11:40 PM Jonathan S. Katz <jkatz@postgresql.org> wrote:

Hi,

Attached is a draft of the release announcement for the upcoming
2021-02-11 cumulative update release. Please review for technical

'closes fixes' maybe better is:
'includes fixes' or 'closes bugs'

'also fixes over 80 bugs'
Maybe drop the 'also'; those same 80 bugs have just been mentioned.

Erik Rijkers

On 2/8/21 11:30 PM, er@xs4all.nl wrote:

On 02/08/2021 11:40 PM Jonathan S. Katz <jkatz@postgresql.org> wrote:

Hi,

Attached is a draft of the release announcement for the upcoming
2021-02-11 cumulative update release. Please review for technical

'closes fixes' maybe better is:
'includes fixes' or 'closes bugs'

'also fixes over 80 bugs'
Maybe drop the 'also'; those same 80 bugs have just been mentioned.

Thanks for the suggestions. I have included them in the updated draft
which I am posting to Noah's reply.

Jonathan

On 2/8/21 6:11 PM, Noah Misch wrote:

On Mon, Feb 08, 2021 at 05:40:41PM -0500, Jonathan S. Katz wrote:

This update also fixes over 80 bugs that were reported in the last several
months. Some of these issues only affect version 13, but may also apply to other
supported versions.

Did you want s/may/many/?

Nope. The bugs may also apply to other versions. Maybe to be clearer
I'll /may/could/?

I made that change.

* Fix an issue with GiST indexes where concurrent insertions could lead to a
corrupt index with entries placed in the wrong pages. You should `REINDEX` any
affected GiST indexes.

For what it's worth, there's little way for a user to confirm whether an index
is affected. (If you've never had more than one connection changing the table
at a time, the table's indexes would be unaffected.)

So Peter Geoghegan and I had a roughly 30 minute back and forth just on
this point. Based on our discussion, we felt it best to go with this
statement.

I think this one is tough to give guidance around, but I don't think a
blanket "anyone who has had concurrent writes to a GiST index should
reindex" is the right answer.

* Fix `CREATE INDEX CONCURRENTLY` to ensure rows from concurrent prepared
transactions are included in the index.

Consider adding a sentence like "Installations that have enabled prepared
transactions should `REINDEX` any concurrently-built indexes." The release
notes say:

+      In installations that have enabled prepared transactions
+      (<varname>max_prepared_transactions</varname> &gt; 0),
+      it's recommended to reindex any concurrently-built indexes in
+      case this problem occurred when they were built.

Oops, I must have missed that in my first build of the release notes (or
I just plain missed it). I agree with that.

* Fix a failure when a PL/pgSQL procedure used `CALL` on another procedure that
has `OUT` parameters did not call execute a `COMMIT` or `ROLLBACK`.

The release notes say the failure happened when the callee _did_ execute a
COMMIT or ROLLBACK:

+     <para>
+      A <command>CALL</command> in a PL/pgSQL procedure, to another
+      procedure that has OUT parameters, would fail if the called
+      procedure did a <command>COMMIT</command>
+      or <command>ROLLBACK</command>.
+     </para>

Oops, good catch. Fixed.

For more details, please see the
[release notes](https://www.postgresql.org/docs/current/release.html).

I recommend pointing this to https://www.postgresql.org/docs/release/, since
the above link now contains only v13 notes.

WFM.

Please see updated draft.

Thanks,

Jonathan

On 02/10/21 10:15, Jonathan S. Katz wrote:

On 2/8/21 6:11 PM, Noah Misch wrote:

On Mon, Feb 08, 2021 at 05:40:41PM -0500, Jonathan S. Katz wrote:

Some of these issues only affect version 13, but may also apply to other
supported versions.

Did you want s/may/many/?

Nope. The bugs may also apply to other versions. Maybe to be clearer
I'll /may/could/?

If that's what was intended, shouldn't it be "but others may also apply
to other supported versions"? ^^^^^^

Surely the ones that "only affect version 13" do not affect other versions,
not even on a 'may' or 'could' basis.

Regards,
-Chap

Hi,

On Wed, Feb 10, 2021 at 10:15:12AM -0500, Jonathan S. Katz wrote:

Please see updated draft.

What about the CVEs, it's my understanding that two security issues have
been fixed; shouldn't they be mentioned as well? Or are those scheduled
to be merged into the announcement at the last minute?

Michael

--
Michael Banck
Projektleiter / Senior Berater
Tel.: +49 2166 9901-171
Fax: +49 2166 9901-100
Email: michael.banck@credativ.de

credativ GmbH, HRB M�nchengladbach 12080
USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 M�nchengladbach
Gesch�ftsf�hrung: Dr. Michael Meskes, J�rg Folz, Sascha Heuer

Unser Umgang mit personenbezogenen Daten unterliegt
folgenden Bestimmungen: https://www.credativ.de/datenschutz

On 2/10/21 10:19 AM, Chapman Flack wrote:

On 02/10/21 10:15, Jonathan S. Katz wrote:

On 2/8/21 6:11 PM, Noah Misch wrote:

On Mon, Feb 08, 2021 at 05:40:41PM -0500, Jonathan S. Katz wrote:

Some of these issues only affect version 13, but may also apply to other
supported versions.

Did you want s/may/many/?

Nope. The bugs may also apply to other versions. Maybe to be clearer
I'll /may/could/?

If that's what was intended, shouldn't it be "but others may also apply
to other supported versions"? ^^^^^^

Surely the ones that "only affect version 13" do not affect other versions,
not even on a 'may' or 'could' basis.

The main goals of the release announcement are to:

* Let people know there are update releases for supported versions that
fix bugs.
* Provide a glimpse at what is fixed so the reader can determine their
level of urgency around updating.
* Direct people on where to download and find out more specifics about
the releases.

I appreciate the suggestions on this sentence, but I don't think the
desired goals hinges on this one word.

Thanks,

Jonathan

On Wed, Feb 10, 2021 at 4:36 PM Michael Banck <michael.banck@credativ.de> wrote:

Hi,

On Wed, Feb 10, 2021 at 10:15:12AM -0500, Jonathan S. Katz wrote:

Please see updated draft.

What about the CVEs, it's my understanding that two security issues have
been fixed; shouldn't they be mentioned as well? Or are those scheduled
to be merged into the announcement at the last minute?

Any potential security announcements are handled independently "out of band".

--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/