| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Resource Owner reassign Locks |
| Date: | 2015-08-25 18:38:07 |
| Message-ID: | 20150825183807.GC19326@awork2.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2015-08-25 18:42:32 | Re: Custom Scans and private data |
| Previous Message | Tom Lane | 2015-08-25 18:33:25 | Re: Resource Owner reassign Locks |