Re: User Level Lock question
От | Nicolas Bazin |
---|---|
Тема | Re: User Level Lock question |
Дата | |
Msg-id | 007401c1ce0c$491f6c10$660d090a@software.ingenico.com.au обсуждение исходный текст |
Ответ на | User Level Lock question ("Lance Ellinghaus" <lellinghaus@yahoo.com>) |
Список | pgsql-hackers |
----- Original Message ----- From: "Lance Ellinghaus" <lellinghaus@yahoo.com> To: "Tom Lane" <tgl@sss.pgh.pa.us> Cc: <pgsql-hackers@postgresql.org> Sent: Saturday, March 16, 2002 6:54 AM Subject: Re: [HACKERS] User Level Lock question > 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. > In INFORMIX you have a similar option except that you have the choice to decide whether the other client blocks or continue, but in any case it returns an error status. You even can set a delay while you accept to be bloked and the lock can be set on database, table or record level. We use table locking to speed up some time consuming processings. I guess it would be better to have at least an error code returned. The application can then choose to ignore the error code. > Does this make any more sense now or have I made it that much more > confusing? > > Lance > > ----- Original Message ----- > From: "Tom Lane" <tgl@sss.pgh.pa.us> > To: "Lance Ellinghaus" <lellinghaus@yahoo.com> > Cc: <pgsql-hackers@postgresql.org> > Sent: Friday, March 15, 2002 9:11 AM > Subject: Re: [HACKERS] User Level Lock question > > > > "Lance Ellinghaus" <lellinghaus@yahoo.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 >
В списке pgsql-hackers по дате отправления: