Re: pg_locks view and user locks

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: pg_locks view and user locks
Дата
Msg-id 6EE64EF3AB31D5448D0007DD34EEB3412A74AD@Herge.rcsinc.local
обсуждение исходный текст
Ответ на pg_locks view and user locks  ("Merlin Moncure" <merlin.moncure@rcsonline.com>)
Список pgsql-hackers
> "Merlin Moncure" <merlin.moncure@rcsonline.com> writes:
> > ... is there any merit to promoting the user lock wrappers out of
> contrib
>
> Dunno.  Yours is the first message I can recall in quite a long time
> indicating that anyone was using userlocks.  I thought the code was
kind
> of dying on the vine.  Of course it's hard to tell whether that's not
> just *because* it's in contrib and not mainstream.  But personally I'd
> like to see some more evidence of use before we promote it.  (And
yeah,
> the API could probably use some cleanup first.)

Well, what's interesting about user locks is that all the real
substantive stuff is already built into the lock manager.  The userlock
contrib module, depending on how you count it, consists of about 10
lines of actual code and only (minimally) exposes the lock manager.
It's like some GPL code has parked itself on top of an existing server
feature (and the copyright on the code in this module is dubious
anyways, it being defined strictly by function).  Plus, there are some
important missing parts lock being able to resolve a locktag back to a
pid and being able to query a lock without acquiring it.

Anyways, there is a reasonable argument to be made for keeping user
locks a loadable module because of the potential for misuse...it's just
too easy to bring down a server with them in place.  A remedy might
involve some combination of the following:

1. rename max_locks_per_transaction to something more reasonable...this
leads one to believe persistent locks are not managed here (but they
are).

2. consider bumping out of memory condition in lock table to 'fatal' to
better guard against a process in runaway lock acquirement...at least
there is a chance for recovery now.

3. enforce a limit to max#locks for each process that is less than the
total maximum size (for example, no single process can acquire more than
half of the entire lock table).

IMO, with some safety and usabilty aspects rolled in, documentation
changes, and re-packaging, plus throw out the gpl stuff, this makes a
reasonable (if somewhat esoteric) bullet point feature for 8.1.

Merlin



В списке pgsql-hackers по дате отправления:

Предыдущее
От: strk
Дата:
Сообщение: Re: pg_restore segfault with pg-CVS
Следующее
От: Devrim GUNDUZ
Дата:
Сообщение: Re: SELECT FOR UPDATE NOWAIT and PostgreSQL 8.0