Re: pg_locks needs a facelift - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: pg_locks needs a facelift
Date
Msg-id 6EE64EF3AB31D5448D0007DD34EEB3415C274A@Herge.rcsinc.local
Whole thread Raw
In response to pg_locks needs a facelift  (Tom Lane)
List 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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Regression tests
Next
From: Tom Lane
Date:
Subject: Re: Feature freeze date for 8.1