On 2013-08-28 13:58:08 +0900, Michael Paquier wrote: > On Tue, Aug 27, 2013 at 11:09 PM, Andres Freund <and...@2ndquadrant.com> > wrote: > > On 2013-08-27 15:34:22 +0900, Michael Paquier wrote: > >> I have been working a little bit more on this patch for the next > >> commit fest. Compared to the previous version, I have removed the part > >> of the code where process running REINDEX CONCURRENTLY was waiting for > >> transactions holding a snapshot older than the snapshot xmin of > >> process running REINDEX CONCURRENTLY at the validation and swap phase. > >> At the validation phase, there was a risk that the newly-validated > >> index might not contain deleted tuples before the snapshot used for > >> validation was taken. I tried to break the code in this area by > >> playing with multiple sessions but couldn't. Feel free to try the code > >> and break it if you can! > > > > Hm. Do you have any justifications for removing those waits besides "I > > couldn't break it"? The logic for the concurrent indexing is pretty > > intricate and we've got it wrong a couple of times without noticing bugs > > for a long while, so I am really uncomfortable with statements like this. > Note that the waits on relation locks are not removed, only the wait > phases involving old snapshots. > > During swap phase, process was waiting for transactions with older > snapshots than the one taken by transaction doing the swap as they > might hold the old index information. I think that we can get rid of > it thanks to the MVCC snapshots as other backends are now able to see > what is the correct index information to fetch.
I don't see MVCC snapshots guaranteeing that. The only thing changed due to them is that other backends see a self consistent picture of the catalog (i.e. not either, neither or both versions of a tuple as earlier). It's still can be out of date. And we rely on those not being out of date. I need to look into the patch for more details. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
