From: anarazel@anarazel.de <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@2ndquadrant.com>
Cc: Paul Hinze <paul.t.hinze@gmail.com>
Cc: pgsql-admin@postgresql.org
Cc: pgsql-hackers@postgresql.org
Subject: Re: [ADMIN] Simultaneous index creates on different schemas cause deadlock?
Date: Thu, 25 Apr 2013 20:57:43 +0200
Message-ID: <7a255af4-951e-4c97-b02b-00eacc3644ce@email.android.com> (raw)
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>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
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().
>>>
>>> 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 than the OP, so it doesn't seem to be to common.
I don't have access to the code ATM an I wonder whether DROP CONCURRENTLY has a similar problem? Depends a bit on how the waiting is done...
Andres
---
Please excuse brevity and formatting - I am writing this on my mobile phone.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-admin@postgresql.org
Cc: andres@anarazel.de, tgl@sss.pgh.pa.us, andres@2ndquadrant.com, paul.t.hinze@gmail.com, pgsql-hackers@postgresql.org
Subject: Re: [ADMIN] Simultaneous index creates on different schemas cause deadlock?
In-Reply-To: <7a255af4-951e-4c97-b02b-00eacc3644ce@email.android.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox