Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index.
Mark Dilger <mark.dilger@enterprisedb.com>
From: Mark Dilger <mark.dilger@enterprisedb.com>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Pavel Borisov <pashkin.elfe@gmail.com>,
Alexander Korotkov <aekorotkov@gmail.com>,
Tom Lane <tgl@sss.pgh.pa.us>,
Noah Misch <noah@leadboat.com>,
Peter Eisentraut <peter@eisentraut.org>,
Aleksander Alekseev <aleksander@timescale.com>,
Postgres hackers <pgsql-hackers@lists.postgresql.org>,
Maxim Orlov <orlovmg@gmail.com>,
Andres Freund <andres@anarazel.de>,
Greg Stark <stark@mit.edu>,
Julien Rouhaud <rjuju123@gmail.com>,
David Steele <david@pgmasters.net>,
Maxim Orlov <m.orlov@postgrespro.ru>,
lubennikovaav@gmail.com
Date: 2024-05-17T20:10:46Z
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
> On May 17, 2024, at 1:00 PM, Peter Geoghegan <pg@bowt.ie> wrote: > > Many different parts of the B-Tree code will fight against allowing > duplicates of the same value to span multiple leaf pages -- this is > especially true for unique indexes. The quick-and-dirty TAP test I wrote this morning is intended to introduce duplicates across page boundaries, not to test for ones that got there by normal database activity. In other words, the TAP test forcibly corrupts the index by changing a value on one side of a boundary to be equal to the value on the other side of the boundary. Prior to the corrupting action the values were all unique. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company