Alvaro Herrera <alvhe...@commandprompt.com> writes:
> Tom Lane wrote:
>> Michael Milligan <mi...@acmeps.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
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
