pg_locks view and user locks
От | Merlin Moncure |
---|---|
Тема | pg_locks view and user locks |
Дата | |
Msg-id | 6EE64EF3AB31D5448D0007DD34EEB3412A74A8@Herge.rcsinc.local обсуждение исходный текст |
Ответы |
Re: pg_locks view and user locks
Re: pg_locks view and user locks |
Список | pgsql-hackers |
I've been knocking around a bit with user level locks and I have a few suggestions/questions: First, the pg_locks view lists user level locks but doesn't really say much about them. For example, for traditional locks we get the xid but for user locks we don't really get anything useful. I looked in lockfuncs.c and didn't see that there would be any real penalty to displaying the offset/block of the user lock, and returning it in request from pg_locks. Is this view frequently queried by system processes? Why would we want to do this? Well it makes resolving a user lock to a specific pid easier...admittedly of dubious value but helpful to me...although if this doesn't fly I can always create an alternate view which serves my purpose (and perhaps add a high level function to the /contrib userlock module). Second, Is there a reason why user level locks are completely undocumented? AFAICT, There is no mention of them in anywhere in the docs, particularly 12.4, which describes methods for application managed concurrency. The availability of cooperative long term locks is (IMO) a really nice feature, particularly for people porting legacy applications which depend on explicit locking (there is some good info in the user lock module which is unfortunately under the GPL). Not complaining or looking for help, just curious why they seemed to have slipped through the cracks. Merlin
В списке pgsql-hackers по дате отправления: