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

Re: PG 8.3.3 - ERROR: lock AccessShareLock on object 16385/16467/0 is already held

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Milligan <milli(at)acmeps(dot)com>
Cc: pgsql-bugs(at)postgreSQL(dot)org
Subject: Re: PG 8.3.3 - ERROR: lock AccessShareLock on object 16385/16467/0 is already held
Date: 2008-09-02 16:52:58
Message-ID: 15583.1220374378@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
[ reincluding the mailing list ]

Michael Milligan <milli(at)acmeps(dot)com> writes:
> Okay, it reproduces and surprise surprise nLocks does overflow...

>  ERROR:  lock AccessShareLock on object 16385/16467/0 is already held
> lock(0x87408a028) id(16385,16467,0,0,0,1) grantMask(a) waitMask(0)
> req(2,0,1,0,0,0,0,0)=3 grant(1,0,1,0,0,0,0,0)=2 wait(0)
> proclock(0x8743a7508) lock(0x87408a028) method(1) proc(0x8743aada8) hold(a)
> locallock(0xb29c78) nLocks(-2147483648) nOwners(2) mOwners(8)

Hah.  Okay, that shows that we'd never have reproduced it with a small
test case.

> So I'm guessing this is not a bug?  Just that for some reason 8.3.3 is
> grabbing more locks than 8.2.6 does and I have to adjust my batch
> processes to break things up into chunks of less than 10 million per
> transaction...  :-/

Well, I'm wondering exactly why 8.3 is taking more locks than 8.2 does,
because AFAICS it shouldn't.  Could you extract a complete example of
what your code does per tuple?  I would like to run a small test case
and just see where the LockAcquire calls come from in each version.
(Or, if you prefer, you can get out gdb and do the legwork yourself...)
It's true that breaking up the transaction is likely to be the best
short-term answer for you, but I think there might be a bug here.

In any case, now that we know that nLocks overflow is actually possible
within real-world transaction lengths, it'd behoove us to do something
about that in 8.4 or beyond.

			regards, tom lane

In response to

Responses

pgsql-bugs by date

Next:From: DanielDate: 2008-09-03 09:03:05
Subject: BUG #4395: internal account lookup faulure
Previous:From: Magnus HaganderDate: 2008-09-02 16:35:15
Subject: Re: BUG #4393: failed toget system metics for terminal services:87

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