Re: Support for REINDEX CONCURRENTLY
Andres Freund <andres@2ndquadrant.com>
From: Andres Freund <andres@2ndquadrant.com>
To: Michael Paquier <michael.paquier@gmail.com>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Peter Eisentraut <peter_e@gmx.net>, Fujii Masao <masao.fujii@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Simon Riggs <simon@2ndquadrant.com>
Date: 2013-03-06T12:09:43Z
Lists: pgsql-hackers
On 2013-03-06 20:59:37 +0900, Michael Paquier wrote: > OK. Patches updated... Please see attached. > With all the work done on those patches, I suppose this is close to being > something clean... Yes, its looking good. There are loads of improvements possible but those can very well be made incrementally. > > I have the feeling we are talking past each other. Unless I miss > > something *there is no* WaitForMultipleVirtualLocks between phase 2 and > > 3. But one WaitForMultipleVirtualLocks for all would be totally > > sufficient. > > > OK, sorry for the confusion. I added a call to WaitForMultipleVirtualLocks > also before phase 3. > Honestly, I am still not very comfortable with the fact that the ShareLock > wait on parent relation is done outside each index transaction for build > and validation... Changed as requested though... Could you detail your concerns a bit? I tried to think it through multiple times now and I still can't see a problem. The lock only ensures that nobody has the relation open with the old index definition in mind... Andres -- 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