From: Tom Lane <tgl@sss.pgh.pa.us>
To: Paul Hinze <paul.t.hinze@gmail.com>
cc: pgsql-admin@postgresql.org, pgsql-hackers@postgresql.org
Subject: Re: [ADMIN] Simultaneous index creates on different schemas cause
	deadlock?
In-reply-to: 
 <CAN=EPw+nwfZFUPKSCiXcJfDc8MSWemtxRgc2i2AtOQwybn3hNw@mail.gmail.com>
References: 
 <CAN=EPw+nwfZFUPKSCiXcJfDc8MSWemtxRgc2i2AtOQwybn3hNw@mail.gmail.com>
Comments: In-reply-to Paul Hinze <paul.t.hinze@gmail.com>
	message dated "Tue, 23 Apr 2013 12:14:16 -0500"
Date: Thu, 25 Apr 2013 13:17:31 -0400
Message-ID: <10635.1366910251@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Paul Hinze <paul.t.hinze@gmail.com> writes:
> [ multiple CREATE INDEX CONCURRENTLY commands will deadlock with each other ]

Hm.  I guess the reason nobody noticed this before now is that generally
the idea with CREATE INDEX CONCURRENTLY is to minimize the impact on
system load, hence you wouldn't do more than one at a time.  Still, it's
surely a POLA violation that you *can't* do more than one at a time.

The cause is that each one will wait for all older snapshots to be
gone --- and it does that before dropping its own snapshot, so that the
other ones will see it as something to be waited out too.

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?

			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