| 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 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2005-01-25 21:41:57 | Re: Vacuum Looping 7.4 |
| Previous Message | Andreas Pflug | 2005-01-25 21:18:39 | Re: Some things I like to pick from the TODO list ... |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ed L. | 2005-01-25 23:49:15 | dbsize patch |
| Previous Message | Merlin Moncure | 2005-01-25 20:06:33 | Re: [HACKERS] userlock changes for 8.1/8.2 |