Re: 2021-02-11 release announcement draft

From: "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: 2021-02-11 release announcement draft
Date: 2021-02-10 15:15:12
Message-ID: 6b3e6e27-83f1-780b-cb70-afbc1aeeeaee@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Attachment Content-Type Size
20210211updaterelease.md text/plain 5.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Chapman Flack 2021-02-10 15:19:26 Re: 2021-02-11 release announcement draft
Previous Message Jonathan S. Katz 2021-02-10 15:14:24 Re: 2021-02-11 release announcement draft