Обсуждение: 2021-11-11 release announcement draft

Hi,

Attached please find a draft of the release announcement for 2021-11-11. 
Please provide any feedback no later than Thu, Nov 11, 2021 0:00 AoE[1].

Thanks!

Jonathan

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

Op 09-11-2021 om 17:25 schreef Jonathan S. Katz:
> 
> Attached please find a draft of the release announcement for 2021-11-11. 

"overflowed-subsraction"  should probably be
"overflowed-subtraction"


Erik

On 11/9/21 12:10 PM, Erik Rijkers wrote:
> Op 09-11-2021 om 17:25 schreef Jonathan S. Katz:
>>
>> Attached please find a draft of the release announcement for 2021-11-11. 
> 
> "overflowed-subsraction"  should probably be
> "overflowed-subtraction"

Actually it should be "overflowed-subtransaction" but regardless, good 
catch.

Fixed in the canonical copy. Thanks!

Jonathan

On Tue, Nov 09, 2021 at 11:25:37AM -0500, Jonathan S. Katz wrote:
> * Fix is when creating a new range type with `CREATE TYPE` that could cause
> problems for later event triggers or subsequent executions of the `CREATE TYPE`
> command.

I don't know what "is when" means, but it seems wrong.

> * Fix restoration of a Portal's snapshot inside a subtransaction, which could
> lead to a crash. For example, this coul doccur in PL/pgSQL when a `COMMIT` is

could occur

-- 
Justin

On 11/9/21 3:19 PM, Justin Pryzby wrote:
> On Tue, Nov 09, 2021 at 11:25:37AM -0500, Jonathan S. Katz wrote:
>> * Fix is when creating a new range type with `CREATE TYPE` that could cause
>> problems for later event triggers or subsequent executions of the `CREATE TYPE`
>> command.
> 
> I don't know what "is when" means, but it seems wrong.
> 
>> * Fix restoration of a Portal's snapshot inside a subtransaction, which could
>> lead to a crash. For example, this coul doccur in PL/pgSQL when a `COMMIT` is
> 
> could occur

Both fixed. Thanks!

Jonathan

On Tue, Nov 09, 2021 at 11:25:37AM -0500, Jonathan S. Katz wrote:
> Attached please find a draft of the release announcement for 2021-11-11.
> Please provide any feedback no later than Thu, Nov 11, 2021 0:00 AoE[1].

> Bug Fixes and Improvements
> --------------------------
> 
> This update fixes over 40 bugs that were reported in the last several months.
> Some of these issues only affect version 14, but could also apply to other
> supported versions.

The part after "but" reads oddly to me.  I would just delete the sentence.

> * Fix `CREATE INDEX CONCURRENTLY` to wait for the latest prepared transactions.
> If you have enabled prepared transactions (`max_prepared_transactions` > 0), you
> should reindex any concurrently built indexes.

The other CONCURRENTLY fix ("Avoid race condition" in the release notes) is
broader, so please replace the above entry with something like this, not even
mentioning prepared transactions:

* Fix causes of `CREATE INDEX CONCURRENTLY` and `REINDEX CONCURRENTLY` writing
corrupt indexes.  You should reindex any concurrently-built indexes.

> * Disallow `ALTER INDEX index ALTER COLUMN col SET (options)`.

I'd drop this since the feature was unusable before.

Please add something like:

* Fix REINDEX CONCURRENTLY to preserve operator class parameters that were
attached to the target index

On 11/9/21 10:39 PM, Noah Misch wrote:
> On Tue, Nov 09, 2021 at 11:25:37AM -0500, Jonathan S. Katz wrote:
>> Attached please find a draft of the release announcement for 2021-11-11.
>> Please provide any feedback no later than Thu, Nov 11, 2021 0:00 AoE[1].
> 
>> Bug Fixes and Improvements
>> --------------------------
>>
>> This update fixes over 40 bugs that were reported in the last several months.
>> Some of these issues only affect version 14, but could also apply to other
>> supported versions.
> 
> The part after "but" reads oddly to me.  I would just delete the sentence.

I'll change to:

"Some of these issues only affect PostgreSQL 14, but may also apply to 
other supported versions of PostgreSQL."

I'm a strong -1 on dropping the sentence altogether given the release 
announcement only highlights fixes known to be in $LATEST, but they may 
also be fixed in releases < $LATEST.

> * Fix causes of `CREATE INDEX CONCURRENTLY` and `REINDEX CONCURRENTLY` writing
> corrupt indexes.  You should reindex any concurrently-built indexes.

Done.

>> * Disallow `ALTER INDEX index ALTER COLUMN col SET (options)`.
> 
> I'd drop this since the feature was unusable before.

Done.

> Please add something like:
> 
> * Fix REINDEX CONCURRENTLY to preserve operator class parameters that were
> attached to the target index

I wondered how widely this affected users, which is why I had initially 
omitted it. I looked at the test cases provided in f255de9a45 and for 
that case, the only reference I could find to the opsclass parameter was 
on[1], and that was after a nontrivial bit of searching.

I know operator classes are more frequently attached to indexes, but I 
haven't seen parameters very often.

Happy to be convinced otherwise (maybe this is used more than I 
realize?), but I'm not sure if we need that bullet point in the release 
announcement.

Thanks,

Jonathan

[1] https://www.postgresql.org/docs/current/textsearch-indexes.html

"Jonathan S. Katz" <jkatz@postgresql.org> writes:
> On 11/9/21 10:39 PM, Noah Misch wrote:
>> Please add something like:
>> * Fix REINDEX CONCURRENTLY to preserve operator class parameters that were
>> attached to the target index

> Happy to be convinced otherwise (maybe this is used more than I 
> realize?), but I'm not sure if we need that bullet point in the release 
> announcement.

FWIW, I agree with Jonathan's choice here.  Opclass parameters are a
very tiny minority use-case as of today.  (Were they not, we'd probably
have found this bug sooner.)

            regards, tom lane

On Wed, Nov 10, 2021 at 11:07 AM Jonathan S. Katz <jkatz@postgresql.org> wrote:
> > * Fix causes of `CREATE INDEX CONCURRENTLY` and `REINDEX CONCURRENTLY` writing
> > corrupt indexes.  You should reindex any concurrently-built indexes.
>
> Done.

As far as I know (correct me if I'm mistaken), all of the CIC/RC bugs
are detectable using amcheck's heapallindexed verification feature.
Why not say as much? Lots of people create lots of indexes with CIC,
and so giving more actionable advice seems worthwhile.

(Unfortunately the same cannot really be said for the 14-only bug in
parallel VACUUM. Seeing what amcheck (or pg_amcheck) have to say is
certainly better than assuming all indexes are corrupt (when they
might have been manually VACUUMed), but it's not the same situation. I
don't think that it's all that unlikely that the B-Tree verification
stuff would miss real problems, since even heapallindexed only notices
the absence of needed index tuples. Whereas the VACUUM bug is mostly
(but not entirely) characterized by the *presence* of "extra", corrupt
index tuples -- tuples that VACUUM should have already removed, but
didn't.

-- 
Peter Geoghegan

On Wed, Nov 10, 2021 at 02:07:43PM -0500, Jonathan S. Katz wrote:
> On 11/9/21 10:39 PM, Noah Misch wrote:
> >On Tue, Nov 09, 2021 at 11:25:37AM -0500, Jonathan S. Katz wrote:
> >>Attached please find a draft of the release announcement for 2021-11-11.
> >>Please provide any feedback no later than Thu, Nov 11, 2021 0:00 AoE[1].
> >
> >>Bug Fixes and Improvements
> >>--------------------------
> >>
> >>This update fixes over 40 bugs that were reported in the last several months.
> >>Some of these issues only affect version 14, but could also apply to other
> >>supported versions.
> >
> >The part after "but" reads oddly to me.  I would just delete the sentence.
> 
> I'll change to:
> 
> "Some of these issues only affect PostgreSQL 14, but may also apply to other
> supported versions of PostgreSQL."

I think that's equivalent to, "Some of these issues only affect PostgreSQL 14.
The issues that only affect PostgreSQL 14 may also apply to other supported
versions of PostgreSQL."  That contradiction is the problem.  This spot calls
for "Not all issues affect all supported versions of PostgreSQL." or
equivalent.

> I'm a strong -1 on dropping the sentence altogether given the release
> announcement only highlights fixes known to be in $LATEST, but they may also
> be fixed in releases < $LATEST.

Okay.

> 11 нояб. 2021 г., в 04:33, Peter Geoghegan <pg@bowt.ie> написал(а):
>
> On Wed, Nov 10, 2021 at 11:07 AM Jonathan S. Katz <jkatz@postgresql.org> wrote:
>>> * Fix causes of `CREATE INDEX CONCURRENTLY` and `REINDEX CONCURRENTLY` writing
>>> corrupt indexes.  You should reindex any concurrently-built indexes.
>>
>> Done.
>
> As far as I know (correct me if I'm mistaken), all of the CIC/RC bugs
> are detectable using amcheck's heapallindexed verification feature.
Yes, but only for B-trees.

Best regards, Andrey Borodin.

On 11/10/21 10:47 PM, Noah Misch wrote:
> On Wed, Nov 10, 2021 at 02:07:43PM -0500, Jonathan S. Katz wrote:
>> On 11/9/21 10:39 PM, Noah Misch wrote:
>>> On Tue, Nov 09, 2021 at 11:25:37AM -0500, Jonathan S. Katz wrote:
>>>> Attached please find a draft of the release announcement for 2021-11-11.
>>>> Please provide any feedback no later than Thu, Nov 11, 2021 0:00 AoE[1].
>>>
>>>> Bug Fixes and Improvements
>>>> --------------------------
>>>>
>>>> This update fixes over 40 bugs that were reported in the last several months.
>>>> Some of these issues only affect version 14, but could also apply to other
>>>> supported versions.
>>>
>>> The part after "but" reads oddly to me.  I would just delete the sentence.
>>
>> I'll change to:
>>
>> "Some of these issues only affect PostgreSQL 14, but may also apply to other
>> supported versions of PostgreSQL."
> 
> I think that's equivalent to, "Some of these issues only affect PostgreSQL 14.
> The issues that only affect PostgreSQL 14 may also apply to other supported
> versions of PostgreSQL."  That contradiction is the problem.  This spot calls
> for "Not all issues affect all supported versions of PostgreSQL." or
> equivalent.

Based on that, I swapped it to:

"The issues listed below affect PostgreSQL 14. Some of these issues may 
also affect other supported versions of PostgreSQL."

which I believe encompasses all of your points.

Jonathan