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  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Postresql 8.0 Beta 3 - SELECT ... FOR UPDATE  (Rod Taylor <pg@rbt.ca>)
Список 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 по дате отправления:

Предыдущее
От: Rod Taylor
Дата:
Сообщение: Re: Postresql 8.0 Beta 3 - SELECT ... FOR UPDATE
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Postresql 8.0 Beta 3 - SELECT ... FOR UPDATE