Обсуждение: Re: [HACKERS] userlock changes for 8.1/8.2

Alvaro wrote:
> Please search this message in the archives:

right. heh. Well, moving on...

tgl wrote:
> Since subids and offnums are only 16 bits, we could pack all of these
> cases into 64 bits with a 16-bit type identifier to distinguish the
> cases.  That would mean that LOCKTAG doesn't get any bigger than it is
> now, and we'd have plenty of room for expansion still with more types.

Ok, this makes perfect sense, kind of what I was saying only better.

The only thing I can add to it at this point is to reorganize the lock
view(s) correspondingly...should be 1 view for each specific lock type
plus 1 generic one for all locks.   A new datum for the generic lock
type (plus some casts) might be worth considering.

Is it possible for one backend (with superuser privs) to release a lock
held by anotether?

Merlin

"Merlin Moncure" <merlin.moncure@rcsonline.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