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

[Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>]

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Tom Lane wrote:
>> Michael Milligan <milli(at)acmeps(dot)com> writes:
>>> Okay, it reproduces and surprise surprise nLocks does overflow...
>>
>> Hah.  Okay, that shows that we'd never have reproduced it with a small
>> test case.

> This hasn't been fixed yet, has it?

Well, it has been addressed anyway...

2008-09-15 21:56  tgl

	* src/include/storage/: lock.h (REL8_1_STABLE), lock.h
	(REL8_3_STABLE), lock.h (REL8_0_STABLE), lock.h (REL8_2_STABLE),
	lock.h: Widen the nLocks counts in local lock tables from int to
	int64.	This forestalls potential overflow when the same table (or
	other object, but usually tables) is accessed by very many
	successive queries within a single transaction.  Per report from
	Michael Milligan.
	
	Back-patch to 8.0, which is as far back as the patch conveniently
	applies.  There have been no reports of overflow in pre-8.3
	releases, but clearly the risk existed all along.  (Michael's
	report suggests that 8.3 may consume lock counts faster than prior
	releases, but with no test case to look at it's hard to be sure
	about that.  Widening the counts seems a good future-proofing
	measure in any event.)

> A customer of ours started hitting this bug too, last week.

Tut tut, customer not on latest point release?

			regards, tom lane