Re: BUG #17485: Records missing from Primary Key index when doing REINDEX INDEX CONCURRENTLY
Alvaro Herrera <alvherre@alvh.no-ip.org>
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Michael Paquier <michael@paquier.xyz>
Cc: Andres Freund <andres@anarazel.de>, Andrey Borodin <x4mmm@yandex-team.ru>, Robert Haas <robertmhaas@gmail.com>, Peter Geoghegan <pg@bowt.ie>, Петър Славов <pet.slavov@gmail.com>, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2022-05-31T09:19:01Z
Lists: pgsql-bugs
On 2022-May-31, Michael Paquier wrote: > Yeah, the tricky part is how to parametize that to be cheap, still > useful. Having a larger number of attributes makes the particular > problem of this thread easier to hit because it enlarges the > validation window in the concurrent build, Hmm, I wonder if it's possible to use an index ON tab (pg_sleep(100ms)) or something like that (perhaps even use an expresion involving an advisory lock acquisition, which is being held by the other session), to widen the window. The stop events patch that A. Korotkov posted [0] would likely be very useful here. [0] https://postgr.es/m/CAPpHfdtSEOHX8dSk9Qp+Z++i4BGQoffKip6JDWngEA+g7Z-XmQ@mail.gmail.com > On my own laptop, the original test of the reporter takes up to 3~4s > to reproduce the issue, for example, all the time, so that's good :) Sadly, my laptop is somehow broken and I haven't reproduced the failure even a single time, and my other regular computers are at high seas (I hope). -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
Commits
-
Revert changes to CONCURRENTLY that "sped up" Xmin advance
- e28bb8851969 15.0 landed
- 042b584c7f7d 14.4 landed
-
Fix possible HOT corruption when RECENTLY_DEAD changes to DEAD while pruning.
- 18b87b201f73 15.0 cited