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