Re: pg_locks needs a facelift

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>, "Jim C(dot) Nasby" <decibel(at)decibel(dot)org>
Subject: Re: pg_locks needs a facelift
Date: 2005-05-04 14:11:34
Message-ID: 6EE64EF3AB31D5448D0007DD34EEB3415C274A@Herge.rcsinc.local
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom wrote:
> Don't worry, I'll veto any immediate removal of functionality ;-)

> The correct way to handle this is to add some better userlock
> functionality and deprecate what's there. We can remove the crufty
> stuff in a release or three after it's been officially deprecated
> ... but there is no reason to remove it immediately. It won't
conflict
> with a better version, just exist alongside.

hm. how about this: leave the userlock contrib module completely alone
and call them 'application locks' (what is the 'user' in userlock?).

Basic points:
1. tweak sources replacing 'user' with 'application' in various places
2. application locks interface is in core project and properly
documented
3. provide 64 bit (or more?) lock space...oid plays no direct role
4. deprecate userlock module but leave it otherwise unchanged.
5. add string based locking to the interface?

Merlin

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2005-05-04 14:15:56 Re: Feature freeze date for 8.1
Previous Message Tom Lane 2005-05-04 14:03:32 Re: Regression tests