Re: 2021-02-11 release announcement draft

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> > 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