From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: crash testing suggestions for 12 beta 1 |
Date: | 2019-06-05 21:32:49 |
Message-ID: | CAH2-Wzm1gbbpjSnkQhx561SBAGHKjjMh3ppg5Q98JvKP-Tjhrg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jun 5, 2019 at 2:11 PM Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
> REINDEX CONCURRENTLY would be one good area to focus on, I think, as
> well as ALTER TABLE ATTACH PARTITION. Maybe also INCLUDE columns in
> GiST, and the stuff in commits 9155580fd, fe280694d and 7df159a62.
Those all seem like good things to target.
Forgive me for droning on about amcheck once more, but maybe it'll
help: amcheck has the capability to detect at least two historic bugs
in CREATE INDEX CONCURRENTLY that made it into stable releases. The
"heapallindexed" verification option's bt_tuple_present_callback()
function has a header comment that talks about this. In short, any
"unhandled" broken hot chain (i.e. broken hot chains that are somehow
not correctly detected and handled) should be reported as corrupt by
amcheck with the "heapallindexed" check, provided the tuple is visible
to verification's heap scan.
The CREATE INDEX CONCURRENTLY bug that Pavan found a couple of years
back while testing the WARM patch is one example. A bug that was
fallout from the DROP INDEX CONCURRENTLY work is another historic
example. Alvaro will recall that this same check had a role in the
"freeze the dead" business.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2019-06-05 21:54:08 | Re: Remove useless associativity/precedence from parsers |
Previous Message | Alvaro Herrera | 2019-06-05 21:11:38 | Re: crash testing suggestions for 12 beta 1 |