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

From Tom Lane
Subject Re: Coping with nLocks overflow
Date
Msg-id 26962.1221566881@sss.pgh.pa.us
Whole thread Raw
In response to Re: Coping with nLocks overflow  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-hackers
Gregory Stark <stark@enterprisedb.com> writes:
> 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?

I considered that, and also considered installing an overflow flag (the
idea being that once nLocks overflows we'd just insist on holding the
lock till transaction end).  But the point isn't clear ... I mean, I
think no one but me even believes anymore in the concept of keeping the
code base minimally safe for INT64_IS_BUSTED machines ;-).  Given the
risk of creating a bug or masking future lock-acquisition bugs, I
thought that adding complexity here wasn't warranted.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Marko Kreen"
Date:
Subject: Re: [patch] fix dblink security hole
Next
From: "Ibrar Ahmed"
Date:
Subject: Re: [Review] fix dblink security hole