Postgres Pro
Downloads
Home   >   mailing lists

Thread: First-draft release notes for back branches are up

First-draft release notes for back branches are up

From
Tom Lane
Date:
See

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=c66a3225e07b5098a796f24588a6b81bfdedd2fd

Please send any corrections by Sunday.

            regards, tom lane

Re: First-draft release notes for back branches are up

From
Tomas Vondra
Date:
On Fri, 06 Nov 2020 17:07:12 -0500
Tom Lane <tgl@sss.pgh.pa.us> wrote:

> See
> 
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=c66a3225e07b5098a796f24588a6b81bfdedd2fd
> 
> Please send any corrections by Sunday.
> 

We should probably include instructions what to do about the BRIN
data corruption fixed by 7577dd8480 - a query to list might be
affected by the bug and should be rebuilt.

regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Re: First-draft release notes for back branches are up

From
Tom Lane
Date:
Tomas Vondra <tomas.vondra@enterprisedb.com> writes:
> We should probably include instructions what to do about the BRIN
> data corruption fixed by 7577dd8480 - a query to list might be
> affected by the bug and should be rebuilt.

Do you have some suggested text?

            regards, tom lane

Re: First-draft release notes for back branches are up

From
Tomas Vondra
Date:
Hi,

On 11/7/20 3:52 AM, Tom Lane wrote:
> Tomas Vondra <tomas.vondra@enterprisedb.com> writes:
>> We should probably include instructions what to do about the BRIN
>> data corruption fixed by 7577dd8480 - a query to list might be
>> affected by the bug and should be rebuilt.
> 
> Do you have some suggested text?
> 

I think this might work:

Fix handling of toasted values in BRIN indexes

This mistake can result in BRIN indexes referencing toasted values,
which may unexpectedly disapper after a cleanup of the table, leading
to errors due to missing chunks:

  ERROR:  missing chunk number 0 for toast value 16433 in pg_toast_16426

Fortunately, this issue only affects BRIN indexes on columns with
toastable data types. While no index corruption due to this bug is
known to have occurred in the field, it is recommended that production
installations REINDEX all brin indexes at a convenient time after
upgrading to X.X.

The list of porentially corrupted BRIN indexes may be obtained using
this query:

  select pg_get_indexdef(oid)
    from pg_class
    where (relkind = 'i')
      and relam = 3580
      and exists (select 1 from pg_attribute
                   where attrelid = pg_class.oid
                     and attlen = -1
                     and attstorage in ('x', 'e'))

It might be better to propose CREATE INDEX CONCURRENTLY, but I don't
think there is a function to generate that SQL.

regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Re: First-draft release notes for back branches are up

From
Tom Lane
Date:
Tomas Vondra <tomas.vondra@enterprisedb.com> writes:
> On 11/7/20 3:52 AM, Tom Lane wrote:
>> Do you have some suggested text?

> I think this might work:

I dunno ... given that we have zero field reports, I doubt this is
something we need to tell every BRIN user to do.  The text I put in
earlier today just recommends reindexing if you see the error.

            regards, tom lane

Re: First-draft release notes for back branches are up

From
Tomas Vondra
Date:
On 11/7/20 11:21 PM, Tom Lane wrote:
> Tomas Vondra <tomas.vondra@enterprisedb.com> writes:
>> On 11/7/20 3:52 AM, Tom Lane wrote:
>>> Do you have some suggested text?
> 
>> I think this might work:
> 
> I dunno ... given that we have zero field reports, I doubt this is
> something we need to tell every BRIN user to do.  The text I put in
> earlier today just recommends reindexing if you see the error.
> 

Sorry, I haven't noticed you already wrote something :-( I agree it's
enough to recommend reindexing only when there's an error.


regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company