Re: userlock changes for 8.1/8.2

> "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.

Fair enough. Doesn't seem right to do this for userlocks and not other
locks.

> 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.

I'll take you up on this one:
Firstly this is application defined, so who knows what the app is doing.
Now for the more selfish reasons :-)

I'm using the user locks to provide ISAM style pessimistic locks for
postgresql...and they work stupendously good for this, better than any
other commercial isam->rdbms implemention that I've seen...they
generally rely on lock tables (yuck) and/or triggers (double yuck) to
provide equivalent functionality.

Anyways, a lot of these ISAM vendors (like AcuCorp AcuCOBOL for example)
provide service monitoring tools that allow you to disconnect a user or
his locks as an administrative function. Since users have been know to
do silly things lock a record and then go to lunch, COBOL admins like
the power of being able to relieve them of their locks without having to
resort to killing their connection. So, from the ISAM point of view,
it's an attractive feature for pg. I make no claims to merit on
technical grounds however.

Merlin