On Wed, Jun 05, 2019 at 02:32:49PM -0700, Peter Geoghegan wrote: > 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.
REINDEX CONCURRENTLY is mostly a mapping of CREATE INDEX CONCURRENTLY + relation swapping + DROP INDEX CONCURRENTLY separated by multiple transactions. In my opinion, the swapping part which renames the indexes and switches the dependencies is the most interesting of the whole set because that's completely new. Are you planning to make sanity checks using pg_catcheck or such? -- Michael
signature.asc
Description: PGP signature
