Re: pg_locks needs a facelift
От | Merlin Moncure |
---|---|
Тема | Re: pg_locks needs a facelift |
Дата | |
Msg-id | 6EE64EF3AB31D5448D0007DD34EEB3415C2716@Herge.rcsinc.local обсуждение исходный текст |
Ответ на | pg_locks needs a facelift (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pg_locks needs a facelift
Re: pg_locks needs a facelift |
Список | pgsql-hackers |
> > well, the old ones are GPL. I've made a few attempts to contact the > > original author...he's MIA. Since 95% of the implementation is in the > > backend, it seems odd to have a GPL interface. > > I agree. Wasn't it you that was proposing to rewrite the module from > scratch to eliminate the GPL restriction? > > regards, tom lane Yep. Actually, the biggest part of this was figuring out what to do about the pg_locks view. Since that's basically decided, all that remains is to decide what if anything to do about the max_locks_per_transaction GUC variable. User locks at the very least are extra-transactional so this could perhaps be renamed. This could possibly hinge on how Alvaro's 'spill to disk' scenario plays out. FWIW, I'm a huge fan of the current behavior which is to drop transactions when running out of lock-space. In any event, I'll rewrite the interface and the documentation for user-locking with minimal changes except to expose more of the locktag structure and remove references to the deprecated and conceptually confusing oid. Merlin
В списке pgsql-hackers по дате отправления: