| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org> |
| Cc: | Noah Misch <noah(at)leadboat(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: 2021-11-11 release announcement draft |
| Date: | 2021-11-10 23:33:08 |
| Message-ID: | CAH2-WzmxAuSSOwo8Ng0fw7EH0BQbx+Ut4+5Ct=YaKW16xa=Y8w@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Nov 10, 2021 at 11:07 AM Jonathan S. Katz <jkatz(at)postgresql(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2021-11-11 00:15:10 | Re: Weird failure in explain.out with OpenBSD |
| Previous Message | Tom Lane | 2021-11-10 23:03:12 | Re: Should AT TIME ZONE be volatile? |