Horton

Re: Reducing overhead of frequent table locks

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Noah Misch <noah@leadboat.com>, Alexey Klyukin <alexk@commandprompt.com>, pgsql-hackers@postgresql.org
Date: 2011-05-14T15:14:27Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix possible "tuple concurrently updated" error in ALTER TABLE.

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