We have recently seen one definite and one probable report of overflow
of the nLocks field of a backend's local lock table:
http://archives.postgresql.org/pgsql-bugs/2008-09/msg00021.php
While it's still unclear exactly why 8.3 seems more prone to this than
earlier releases, the general shape of the problem seems clear enough.
We have many code paths that intentionally take a lock on some object
and leave it locked until end of transaction. Repeat such a command on
the same object enough times within one transaction, and voila,
overflow. What's news, perhaps, is that we've reached a performance
level where this can actually happen within transactions of lengths that
people might try to run.
I'm considering that a simple solution to this might be to widen nLocks
from int to int64. This would definitely fix it on machines that have
working int64 arithmetic, and if there are any left that do not, they're
probably not fast enough to encounter the overflow in real-world usage
anyway. For machines that aren't native 64-bit it would add a couple
of cycles to lock acquisition/release, but that's hardly likely to be
measurable compared to all the other work done in
LockAcquire/LockRelease.
Comments, objections?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
