"Gregory Stark" <stark@enterprisedb.com> writes:
> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
>
>> I didn't have any luck reproducing either of these behaviors --- maybe
>> it's data-dependent. Can you extract a test case?
>
> I haven't been able to reproduce this either but I produced an entirely
> different problem:
>
> postgres=# create index concurrently dg5 on doc using gin (to_tsvector('english',d));
> ERROR: deadlock detected
> DETAIL: Process 7076 waits for ShareLock on unrecognized locktag type 5; blocked by process 10497.
> Process 10497 waits for ShareUpdateExclusiveLock on relation 24656 of database 11511; blocked by process 7076.
Further poking around shows that the "unrecognized locktag" is because
lmgr.c:DescribeLockTag was never taught about virtual xids. Ie something like
this (untested):
--- lmgr.c 04 Jan 2008 15:12:37 +0000 1.95
+++ lmgr.c 07 Jan 2008 15:54:49 +0000
@@ -739,6 +739,12 @@ tag->locktag_field2, tag->locktag_field1);
break;
+ case LOCKTAG_VIRTUALTRANSACTION:
+ appendStringInfo(buf,
+ _("virtual transaction %d/%u"),
+ tag->locktag_field1,
+ tag->locktag_field2);
+ break; case LOCKTAG_TRANSACTION: appendStringInfo(buf,
_("transaction%u"),
The pid it's waiting on is long since gone but looks like it was probably an
autovacuum process. I have a vague recollection that you had rigged CREATE
INDEX CONCURRENTLY to ignore vacuum processes when checking for conflicting
processes. Since any such process will be blocked on our session-level
ShareUpdateExclusiveLock it will always cause a deadlock and we would rather
it just hang out and wait until our index build is finished.
On the other hand we can't just ignore all vacuums because someone could issue
a manual vacuum inside a transaction (I think?). But this is a general problem
with all the places where we check if another transaction is just running
vacuum, such as checking for globalxmin. We should only be ignoring
transactions which were started just to execute a vacuum.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about
EnterpriseDB'sPostgreSQL training!