Обсуждение: 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