Re: Resource Owner reassign Locks - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Resource Owner reassign Locks
Date
Msg-id 16303.1440528787@sss.pgh.pa.us
Whole thread Raw
In response to Re: Resource Owner reassign Locks  (Andres Freund <andres@anarazel.de>)
Responses Re: Resource Owner reassign Locks  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Custom Scans and private data
Next
From: Joe Conway
Date:
Subject: Re: pg_controldata output alignment regression