From: | Greg Copeland <greg(at)CopelandConsulting(dot)Net> |
---|---|
To: | Lance Ellinghaus <lellinghaus(at)yahoo(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgresSQL Hackers Mailing List <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: User Level Lock question |
Date: | 2002-03-15 21:03:11 |
Message-ID: | 1016226192.24599.42.camel@mouse.copelandconsulting.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Are you trying to do a select for update?
Greg
On Fri, 2002-03-15 at 13:54, Lance Ellinghaus wrote:
> I know it does not sound like something that would need to be done, but here
> is why I am looking at doing this...
>
> I am trying to replace a low level ISAM database with PostgreSQL. The low
> level ISAM db allows locking a record during a read to allow Exclusive
> access to the record for that process. If someone tries to do a READ
> operation on that record, it is skipped. I have to duplicate this
> functionality. The application also allows locking multiple records and then
> unlocking individual records or unlocking all of them at once. This cannot
> be done easily with PostgreSQL unless I add a "status" field to the records
> and manage them. This can be done, but User Level Locks seem like a much
> better solution as they provide faster locking, no writes to the database,
> when the backend quits all locks are released automatically, and I could
> lock multiple records and then clear them as needed. They also exist outside
> of transactions!
>
> So my idea was to use User Level Locks on records and then include a test on
> the lock status in my SELECT statements to filter out any records that have
> a User Level Lock on it. I don't need to set it during the query, just test
> if there is a lock to remove them from the query. When I need to do a true
> lock during the SELECT, I can do it with the supplied routines.
>
> Does this make any more sense now or have I made it that much more
> confusing?
>
> Lance
>
> ----- Original Message -----
> From: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> To: "Lance Ellinghaus" <lellinghaus(at)yahoo(dot)com>
> Cc: <pgsql-hackers(at)postgresql(dot)org>
> Sent: Friday, March 15, 2002 9:11 AM
> Subject: Re: [HACKERS] User Level Lock question
>
>
> > "Lance Ellinghaus" <lellinghaus(at)yahoo(dot)com> writes:
> > > Is there an easy way to test the lock on a user level lock without
> actually
> > > issuing the lock?
> >
> > Why would you ever want to do such a thing? If you "test" the lock but
> > don't actually acquire it, someone else might acquire the lock half a
> > microsecond after you look at it --- and then what does your test result
> > mean? It's certainly unsafe to take any action based on assuming that
> > the lock is free.
> >
> > I suspect what you really want is a conditional acquire, which you can
> > get (in recent versions) using the dontWait parameter to LockAcquire.
> >
> > regards, tom lane
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2002-03-15 22:24:02 | Re: User Level Lock question |
Previous Message | Vince Vielhaber | 2002-03-15 20:06:45 | Re: insert statements |