Re: Coping with nLocks overflow - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: Coping with nLocks overflow
Date
Msg-id 87d4j4o6fy.fsf@oxford.xeocode.com
Whole thread Raw
In response to Coping with nLocks overflow  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Coping with nLocks overflow  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:

> 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
> ...
> Comments, objections?

In that case the problem could have been postponed by making nlocks unsigned.
Not much point in that I guess.

Alternatively perhaps we could indicate when taking a lock that we intend to
hold the lock until the end of the transaction. In that case we don't need the
usage counter at all and could just mark it with a special value which we
never increment or decrement just wait until we release all locks at the end
of transaction?

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support!


pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: Common Table Expressions (WITH RECURSIVE) patch
Next
From: Ibrar Ahmed
Date:
Subject: [Review] fix dblink security hole