User-Agent: K-9 Mail for Android
In-Reply-To: <14978.1366915821@sss.pgh.pa.us>
References: 
 <CAN=EPw+nwfZFUPKSCiXcJfDc8MSWemtxRgc2i2AtOQwybn3hNw@mail.gmail.com>
	<10635.1366910251@sss.pgh.pa.us>
	<20130425173446.GH11158@awork2.anarazel.de>
	<14978.1366915821@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=UTF-8
Subject: Re: [ADMIN] Simultaneous index creates on different schemas cause
	deadlock?
From: "anarazel@anarazel.de" <andres@anarazel.de>
Date: Thu, 25 Apr 2013 20:57:43 +0200
To: Tom Lane <tgl@sss.pgh.pa.us>,Andres Freund <andres@2ndquadrant.com>
CC: Paul Hinze <paul.t.hinze@gmail.com>, pgsql-admin@postgresql.org,
	pgsql-hackers@postgresql.org
Message-ID: <7a255af4-951e-4c97-b02b-00eacc3644ce@email.android.com>
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


Tom Lane <tgl@sss.pgh.pa.us> schrieb:

>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().
>>>=20
>>> 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

Fine with me, especially as nobody seems to have complained so far other th=
an the OP, so it doesn't seem to be to common.=20
I don't have access to the code ATM an I wonder whether DROP CONCURRENTLY h=
as a similar problem? Depends a bit on how the waiting is done...

Andres

---=20
Please excuse brevity and formatting - I am writing this on my mobile phone.


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