Re: Reducing overhead of frequent table locks - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Reducing overhead of frequent table locks
Date
Msg-id 21022.1305386067@sss.pgh.pa.us
Whole thread Raw
In response to Re: Reducing overhead of frequent table locks  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, May 13, 2011 at 11:05 PM, Noah Misch <noah@leadboat.com> wrote:
>> Incidentally, I used the term "local lock" because I assumed fast-path locks
>> would still go through the lock manager far enough to populate the local lock
>> table.  But there may be no reason to do so.

> Oh, good point.  I think we probably WOULD need to update the local
> lock lock hash table.

I haven't read this thread closely, but the general behavior of the
backend assumes that it's very very cheap to re-acquire a lock that's
already held by the current transaction.  It's probably worth
maintaining a local counter just so you can keep that being true, even
if there were no other need for it.  (Since I've not read the thread,
I'll refrain from asking how you're gonna clean up at transaction end
if there's no local memory of what locks you hold.)
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: SSI-related code drift between index_getnext() and heap_hot_search_buffer()
Next
From: Leon Smith
Date:
Subject: Exporting closePGconn from libpq