Re: advisory locks and permissions - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: advisory locks and permissions
Date
Msg-id b42b73150609220956v31e56e3ei5b3038fa51bd783b@mail.gmail.com
Whole thread Raw
In response to Re: advisory locks and permissions  ("Jim C. Nasby" <jim@nasby.net>)
Responses Re: advisory locks and permissions  ("Jim C. Nasby" <jim@nasby.net>)
Re: advisory locks and permissions  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 9/22/06, Jim C. Nasby <jim@nasby.net> wrote:
> This is why I suggested we set aside some range of numbers that should
> not be used. Doing so would allow adding a better-managed
> numbering/naming scheme in the future.

the whole point about advisory locks is that the provided lock space
is unmanaged. for example, in the ISAM system I wrote which hooked
into the acucobol virtual file system interface, I used  a global
sequence for row level pessimistic locking but reserved the 48th bit
for table level locks.  This system was extremely effective.  on the
current system I'm working on I use them to lock sequence oid's plus a
high bit indicator for what i am doing.  in short, advisory locks are
application-defined in concept.

merlin


pgsql-hackers by date:

Previous
From: Stefan Kaltenbrunner
Date:
Subject: Re: -HEAD planner issue wrt hash_joins on dbt3 ?
Next
From: Tom Lane
Date:
Subject: Re: 8.3 Development Cycle