Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] userlock changes for 8.1/8.2

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>
Cc: "Alvaro Herrera" <alvherre(at)dcc(dot)uchile(dot)cl>,pgsql-hackers(at)postgresql(dot)org, pgsql-patches(at)postgresql(dot)org
Subject: Re: [HACKERS] userlock changes for 8.1/8.2
Date: 2005-01-25 21:22:25
Message-ID: 6920.1106688145@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
"Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com> writes:
> Is it possible for one backend (with superuser privs) to release a lock
> held by anotether?

As of 8.0 this is not possible for regular locks, because there'd be no
way to update the other backend's internal data structure that shows
what locks it holds.  I think though that there is no corresponding
structure for userlocks and so in principle it could be done for
userlocks.

Whether it's a good idea is a whole 'nother question.  It strikes me
as a foot-gun with no evident redeeming social value.  In particular,
there would most likely be some state inside the client app showing
that it holds this userlock, and so the inability-to-update-state
problem comes right back at that level.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2005-01-25 21:41:57
Subject: Re: Vacuum Looping 7.4
Previous:From: Andreas PflugDate: 2005-01-25 21:18:39
Subject: Re: Some things I like to pick from the TODO list ...

pgsql-patches by date

Next:From: Ed L.Date: 2005-01-25 23:49:15
Subject: dbsize patch
Previous:From: Merlin MoncureDate: 2005-01-25 20:06:33
Subject: Re: [HACKERS] userlock changes for 8.1/8.2

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group