Re: pg_locks view and user locks

From: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_locks view and user locks
Date: 2004-09-14 17:20:10
Message-ID: 6EE64EF3AB31D5448D0007DD34EEB3412A74AD@Herge.rcsinc.local
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)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

Browse pgsql-hackers by date

  From Date Subject
Next Message Devrim GUNDUZ 2004-09-14 17:33:19 Re: SELECT FOR UPDATE NOWAIT and PostgreSQL 8.0
Previous Message strk 2004-09-14 15:05:08 Re: pg_restore segfault with pg-CVS