public inbox for [email protected]help / color / mirror / Atom feed
pg_locks view and user locks 6+ messages / 4 participants [nested] [flat]
* pg_locks view and user locks @ 2004-09-13 17:34 Merlin Moncure <[email protected]> 0 siblings, 2 replies; 6+ messages in thread From: Merlin Moncure @ 2004-09-13 17:34 UTC (permalink / raw) To: [email protected]; +Cc: pgsql-docs 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 ^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: pg_locks view and user locks @ 2004-09-13 19:36 Peter Eisentraut <[email protected]> parent: Merlin Moncure <[email protected]> 1 sibling, 1 reply; 6+ messages in thread From: Peter Eisentraut @ 2004-09-13 19:36 UTC (permalink / raw) To: Merlin Moncure <[email protected]>; [email protected] Merlin Moncure wrote: > 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). That's the whole problem. I don't think anyone objects to the user lock principle, but as long as it's GPL, we won't support it. It was probably a mistake to accept this module in the first place. I believe some people have been trying to get the module relicensed, but that evidently never happened. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: [HACKERS] pg_locks view and user locks @ 2004-09-13 20:02 Alvaro Herrera <[email protected]> parent: Merlin Moncure <[email protected]> 1 sibling, 1 reply; 6+ messages in thread From: Alvaro Herrera @ 2004-09-13 20:02 UTC (permalink / raw) To: Merlin Moncure <[email protected]>; +Cc: [email protected]; pgsql-docs On Mon, Sep 13, 2004 at 01:34:05PM -0400, Merlin Moncure wrote: > 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. ISTM it would be better to have pg_locks show only system locks, and another view, say pg_userlocks, to show user locks. This would allow to show different data; for example, the PID of the process involved. What's more, user locks and system locks never conflict, so it seems wrong to show them together. Another option would be to add another column to pg_locks to say what lockmethod (1 for system, 2 for user) is used in each lock. Maybe we want to separate locks even more, and use one table to show xact locks, another to show table locks, and yet another to show user locks. But maybe this is a bad idea right from the start. > Is this view frequently queried by system processes? I don't think there is a lot of server-side stuff (aside from possible UDFs) that use pg_locks directly. It's there only for user convenience. -- Alvaro Herrera (<alvherre[a]dcc.uchile.cl>) "Someone said that it is at least an order of magnitude more work to do production software than a prototype. I think he is wrong by at least an order of magnitude." (Brian Kernighan) ^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: [HACKERS] pg_locks view and user locks @ 2004-09-13 20:12 Merlin Moncure <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Merlin Moncure @ 2004-09-13 20:12 UTC (permalink / raw) To: Peter Eisentraut <[email protected]>; +Cc: [email protected]; pgsql-docs > Merlin Moncure wrote: > > 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). > > That's the whole problem. I don't think anyone objects to the user lock > principle, but as long as it's GPL, we won't support it. It was > probably a mistake to accept this module in the first place. I believe > some people have been trying to get the module relicensed, but that > evidently never happened. Well, the lock module itself is nothing more than some wrappers for the system lock manager functions (LockAcquire,etc) in C and wrappers for those in SQL, plus a makefile and some basic documentation...in other words almost nothing. If the 'userlock' module author can't be found or refuses to open his module, why not simply rewrite it? It's extremely small. This also gives an opportunity to add some missing parts, like resolving a lock to a pid and better error handling. In any case, IMHO it is worthwhile to flesh out 12.3, adding user locks (simply listing as a lock type), 12.4 with usage of above, perhaps with an example. Also a mention of userlocks in 43.32 and possibly a new entry in this section, depending on how they get handled per my suggestion wrt pg_locks. Also possibly a note in 16.4.8 (postgresql.conf entry for max_locks_per_transaction) describing the interaction between this parameter and user locks (aside: is there any?). Certain aspects of these changes would of course depend on the feasibility of moving some of the lock interfaces into the main project. I'd be willing to have a stab at the above, is it worthwhile? Merlin ^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: pg_locks view and user locks @ 2004-09-13 20:39 Tom Lane <[email protected]> parent: Peter Eisentraut <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2004-09-13 20:39 UTC (permalink / raw) To: Peter Eisentraut <[email protected]>; +Cc: Merlin Moncure <[email protected]>; [email protected] Peter Eisentraut <[email protected]> writes: > That's the whole problem. I don't think anyone objects to the user lock > principle, but as long as it's GPL, we won't support it. It was > probably a mistake to accept this module in the first place. I believe > some people have been trying to get the module relicensed, but that > evidently never happened. I said some time ago that I would pester contrib authors about fixing license issues, but it still hasn't gotten to the top of my to-do list :-( AFAIK nothing at all has been done on this score. If Merlin is hot about contrib/userlock right now, he's welcome to try to contact the original author and get this dealt with. The point about not importing documentation from a mislicensed contrib module is valid IMHO. regards, tom lane ^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: [HACKERS] pg_locks view and user locks @ 2004-09-13 21:31 Tom Lane <[email protected]> parent: Alvaro Herrera <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2004-09-13 21:31 UTC (permalink / raw) To: Alvaro Herrera <[email protected]>; +Cc: Merlin Moncure <[email protected]>; [email protected]; pgsql-docs Alvaro Herrera <[email protected]> writes: > ISTM it would be better to have pg_locks show only system locks, and > another view, say pg_userlocks, to show user locks. This would allow to > show different data; for example, the PID of the process involved. I think this is a bad idea, at least for the base-level view, because it would imply that it's impossible to get a truly simultaneous view of the state of all the locks. It would certainly be a bad idea to so separate xact and table locks. I'd prefer to extend the present approach and add columns that are NULL when the type of lock isn't relevant to them. > Another option would be to add another column to pg_locks to say what > lockmethod (1 for system, 2 for user) is used in each lock. How about a text column with values "TABLE", "XACT", "USER"? regards, tom lane ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2004-09-13 21:31 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2004-09-13 17:34 pg_locks view and user locks Merlin Moncure <[email protected]> 2004-09-13 19:36 ` Peter Eisentraut <[email protected]> 2004-09-13 20:39 ` Tom Lane <[email protected]> 2004-09-13 20:02 ` Alvaro Herrera <[email protected]> 2004-09-13 21:31 ` Tom Lane <[email protected]> 2004-09-13 20:12 Re: [HACKERS] pg_locks view and user locks Merlin Moncure <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox