Tom Lane wrote:
Andrew Dunstan <and...@dunslane.net> writes:
What you're missing is that we need to compare the lockdeps of each item
(i.e. both the candidate item and the running item) with all the deps
(not just the lockdeps) of the other item. If neither item has any
lockdeps there will be no conflict. This will allow concurrent index
creation, since neither item will have any lockdeps. But it will prevent
us selecting a create index that conflicts with a running FK creation or
vice versa.
Oh, I see, you're using the deps as a proxy for the shared locks the
operation will acquire. Yeah, that might work. Seems like it's nearly
a one-liner fix, too.
Well, what I have in mind is a bit bigger, but not large. See attached
patch.
cheers
andrew
*** pg_backup_archiver.c 2009-04-10 00:09:57.000000000 -0400
--- pg_backup_archiver-fix.c 2009-04-10 19:22:07.000000000 -0400
***************
*** 3423,3433 ****
if (slots[i].args == NULL)
continue;
running_te = slots[i].args->te;
for (j = 0; j < te->nLockDeps && !conflicts; j++)
{
! for (k = 0; k < running_te->nLockDeps; k++)
{
! if (te->lockDeps[j] == running_te->lockDeps[k])
{
conflicts = true;
break;
--- 3423,3450 ----
if (slots[i].args == NULL)
continue;
running_te = slots[i].args->te;
+ /* does the candidate item require an exclusive lock that
+ * would block on or conflict with the running item?
+ */
for (j = 0; j < te->nLockDeps && !conflicts; j++)
{
! for (k = 0; k < running_te->nDeps; k++)
{
! if (te->lockDeps[j] == running_te->dependencies[k])
! {
! conflicts = true;
! break;
! }
! }
! }
! /* or does the running item hold an exclusive lock that
! * would block or conflict with the candidate item?
! */
! for (j = 0; j < running_te->nLockDeps && !conflicts; j++)
! {
! for (k = 0; k < te->nDeps; k++)
! {
! if (running_te->lockDeps[j] == te->dependencies[k])
{
conflicts = true;
break;
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
