From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@2ndquadrant.com>
cc: Paul Hinze <paul.t.hinze@gmail.com>, pgsql-admin@postgresql.org,
	pgsql-hackers@postgresql.org
Subject: Re: [ADMIN] Simultaneous index creates on different schemas cause
	deadlock?
In-reply-to: <20130425173446.GH11158@awork2.anarazel.de>
References: 
 <CAN=EPw+nwfZFUPKSCiXcJfDc8MSWemtxRgc2i2AtOQwybn3hNw@mail.gmail.com>
	<10635.1366910251@sss.pgh.pa.us>
	<20130425173446.GH11158@awork2.anarazel.de>
Comments: In-reply-to Andres Freund <andres@2ndquadrant.com>
	message dated "Thu, 25 Apr 2013 19:34:46 +0200"
Date: Thu, 25 Apr 2013 14:50:21 -0400
Message-ID: <14978.1366915821@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Andres Freund <andres@2ndquadrant.com> writes:
> On 2013-04-25 13:17:31 -0400, Tom Lane wrote:
>> Since we know that C.I.C. executes in its own transaction, and there
>> can't be more than one on the same table due to locking, it seems to me
>> that it'd be safe to drop our own snapshot before waiting for other
>> xacts to end.  That is, we could just rearrange the last few steps in
>> DefineIndex(), taking care to save snapshot->xmin before we destroy the
>> snapshot so that we still have that value to pass to
>> GetCurrentVirtualXIDs().
>> 
>> Anybody see a flaw in that solution?

> Except that it still will unnecessarily wait for other CICs, just not
> deadlock, I don't see a problem. We could have a PROC_IN_CIC flag or
> something so we can ignore other index creations, but I am not sure if
> its worth the complication.

I'm not sure it's a good idea to ignore other CICs altogether --- they
could be executing user-defined index functions that do strange things
like consult other tables.  Since this seems to me to be a bit outside
the intended use-case for CIC anyway, I think it's good enough if they
just don't deadlock.

			regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers