Re: Support for REINDEX CONCURRENTLY
Andres Freund <andres@2ndquadrant.com>
From: Andres Freund <andres@2ndquadrant.com>
To: Michael Paquier <michael.paquier@gmail.com>
Cc: Fujii Masao <masao.fujii@gmail.com>,
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>,
Peter Eisentraut <peter_e@gmx.net>, Tom Lane <tgl@sss.pgh.pa.us>,
Simon Riggs <simon@2ndquadrant.com>
Date: 2013-08-28T13:02:52Z
Lists: pgsql-hackers
On 2013-08-28 13:58:08 +0900, Michael Paquier wrote: > On Tue, Aug 27, 2013 at 11:09 PM, Andres Freund <andres@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
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Background worker processes
- da07a1e85651 9.3.0 cited
-
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
- 3c84046490be 9.3.0 cited
-
Work around unportable behavior of malloc(0) and realloc(NULL, 0).
- 09ac603c36d1 9.3.0 cited
-
Properly set relpersistence for fake relcache entries.
- beb850e1d873 9.3.0 cited