First-draft release notes for back branches are up
On Fri, 06 Nov 2020 17:07:12 -0500
Tom Lane <tgl@sss.pgh.pa.us> wrote:
See
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
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
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
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
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