Skip site navigation (1) Skip section navigation (2)

Re: Index trouble with 8.3b4

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Index trouble with 8.3b4
Date: 2008-01-07 16:15:35
Message-ID: 87y7b1628o.fsf@oxford.xeocode.com (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-hackers
"Gregory Stark" <stark(at)enterprisedb(dot)com> writes:

> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)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's PostgreSQL training!

In response to

Responses

pgsql-hackers by date

Next:From: Holger HoffstaetteDate: 2008-01-07 16:33:53
Subject: Re: VACUUM FULL out of memory
Previous:From: Kevin GrittnerDate: 2008-01-07 16:07:24
Subject: Re: OUTER JOIN performance regression remains in8.3beta4

pgsql-general by date

Next:From: Martijn van OosterhoutDate: 2008-01-07 16:16:08
Subject: Re: Hash Indexes
Previous:From: Andrew SullivanDate: 2008-01-07 16:03:43
Subject: Re: Hash Indexes

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group