Re: Postresql 8.0 Beta 3 - SELECT ... FOR UPDATE
| От | Bruce Momjian |
|---|---|
| Тема | Re: Postresql 8.0 Beta 3 - SELECT ... FOR UPDATE |
| Дата | |
| Msg-id | 200411250347.iAP3lvW05219@candle.pha.pa.us обсуждение исходный текст |
| Ответ на | Re: Postresql 8.0 Beta 3 - SELECT ... FOR UPDATE (Rod Taylor <pg@rbt.ca>) |
| Ответы |
Re: Postresql 8.0 Beta 3 - SELECT ... FOR UPDATE
Re: Postresql 8.0 Beta 3 - SELECT ... FOR UPDATE |
| Список | pgsql-hackers |
Rod Taylor wrote: > On Wed, 2004-11-24 at 22:13 -0500, Bruce Momjian wrote: > > > > We have discussed this at length and no one could state why having an > > timeout per lock is any better than using a statement_timeout. > > Actually, I hit one. > > I have a simple queue and a number of processes pulling jobs out of the > queue. Due to transactional requirements, the database is appropriate > for a first cut. > > Anyway, a statement_timeout of 100ms is usually plenty to determine that > the job is being processed, and for one of the pollers to move on, but > every once in a while a large job (4 to 5MB chunk of data) would find > itself in the queue which takes more than 100ms to pull out. > > Not a big deal, just bump the timeout in this case. > > Anyway, it shows a situation where it would be nice to differentiate > between statement_timeout and lock_timeout OR it demonstrates that I > should be using userlocks... Wouldn't a LOCK NOWAIT be a better solution? That is new in 8.0. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
В списке pgsql-hackers по дате отправления: