Re: Coping with nLocks overflow

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Coping with nLocks overflow
Date: 2008-09-16 08:12:17
Message-ID: 87d4j4o6fy.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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!

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ibrar Ahmed 2008-09-16 08:13:36 [Review] fix dblink security hole
Previous Message David Fetter 2008-09-16 05:41:14 Re: Common Table Expressions (WITH RECURSIVE) patch