Horton

Re: Resource Owner reassign Locks

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

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Jeff Janes <jeff.janes@gmail.com>, Michael Paquier <michael.paquier@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2015-08-25T18:53:07Z
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. Add a small cache of locks owned by a resource owner in ResourceOwner.

Andres Freund <andres@anarazel.de> writes:
> On 2015-08-25 14:33:25 -0400, Tom Lane wrote:
>> (IOW, yeah, certainly third-party code could create a new *instance* of
>> the ResourceOwner data structure, but they would not have any knowledge of
>> what's inside unless they had hacked the core code.)

> What I was thinking is that somebody created a new resowner, did
> something, and then called LockReleaseCurrentOwner() (because no locks
> are needed anymore), or LockReassignCurrentOwner() (say you want to
> abort a subtransaction, but do *not* want the locks to be released).

> Anyway, I slightly lean towards having wrappers, you strongly against,
> so that makes it an easy call.

Well, I'm not "strongly" against them, just trying to understand whether
there's a plausible argument that someone is calling these functions from
extensions.  I'm not hearing one ... for one thing, I don't believe there
are any extensions playing games with transaction/lock semantics.  (My
Salesforce colleagues have done some of that, and no you can't get far
without changing the core code.)

			regards, tom lane