On 2013-03-06 21:19:57 +0900, Michael Paquier wrote: > On Wed, Mar 6, 2013 at 9:09 PM, Andres Freund <and...@2ndquadrant.com>wrote: > > > 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... > > > I am making a comparison with CREATE INDEX CONCURRENTLY where the ShareLock > wait is made inside the build and validation transactions. Was there any > particular reason why CREATE INDEX CONCURRENTLY wait is done inside a > transaction block? > That's my only concern.
Well, it needs to be executed in a transaction because it needs a valid resource owner and a previous CommitTransactionCommand() will leave that at NULL. And there is no reason in the single-index case of CREATE INDEX CONCURRENTLY to do it in a separate transaction. 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