"Gregory Stark" <[EMAIL PROTECTED]> writes: > "Tom Lane" <[EMAIL PROTECTED]> 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's PostgreSQL training! ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org