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" <[EMAIL PROTECTED]> > To: "Lance Ellinghaus" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Friday, March 15, 2002 9:11 AM > Subject: Re: [HACKERS] User Level Lock question > > > > "Lance Ellinghaus" <[EMAIL PROTECTED]> 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
signature.asc
Description: This is a digitally signed message part
