Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index.
Pavel Borisov <pashkin.elfe@gmail.com>
From: Pavel Borisov <pashkin.elfe@gmail.com>
To: Mark Dilger <mark.dilger@enterprisedb.com>
Cc: Anastasia Lubennikova <a.lubennikova@postgrespro.ru>, Postgres hackers <pgsql-hackers@lists.postgresql.org>,
Peter Geoghegan <pg@bowt.ie>
Date: 2021-03-01T20:23:23Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
amcheck: Optimize speed of checking for unique constraint violation
- cdd6ab9d1f53 18.0 landed
-
amcheck: Report an error when the next page to a leaf is not a leaf
- 97e5b0026fc2 17.0 landed
-
amcheck: Don't load the right sibling page into BtreeCheckState
- 0b5c16124811 17.0 landed
-
amcheck: Refactoring the storage of the last visible entry
- 532d94fec32a 17.0 landed
-
Teach contrib/amcheck to check the unique constraint violation
- 5ae2087202af 17.0 landed
-
Add macros in hash and btree AMs to get the special area of their pages
- d16773cdc862 15.0 cited
> > If bt_index_check() and bt_index_parent_check() are to have this > functionality, shouldn't there be an option controlling it much as the > option (heapallindexed boolean) controls checking whether all entries in > the heap are indexed in the btree? It seems inconsistent to have an option > to avoid checking the heap for that, but not for this. Alternately, this > might even be better coded as its own function, named something like > bt_unique_index_check() perhaps. I hope Peter might advise? > As for heap checking, my reasoning was that we can not check whether a unique constraint violated by the index, without checking heap tuple visibility. I.e. we can have many identical index entries without uniqueness violated if only one of them corresponds to a visible heap tuple. So heap checking included in my patch is _necessary_ for unique constraint checking, it should not have an option to be disabled, otherwise, the only answer we can get is that unique constraint MAY be violated and may not be, which is quite useless. If you meant something different, please elaborate. I can try to rewrite unique constraint checking to be done after all others check but I suppose it's the performance considerations are that made previous amcheck routines to do many checks simultaneously. I tried to stick to this practice. It's also not so elegant to duplicate much code to make uniqueness checks independently and the resulting patch will be much bigger and harder to review. Anyway, your and Peter's further considerations are always welcome. -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>