Re: Postresql 8.0 Beta 3 - SELECT ... FOR UPDATE

Поиск
Список
Период
Сортировка
От Rod Taylor
Тема Re: Postresql 8.0 Beta 3 - SELECT ... FOR UPDATE
Дата
Msg-id 1101353625.44437.127.camel@home
обсуждение исходный текст
Ответ на Re: Postresql 8.0 Beta 3 - SELECT ... FOR UPDATE  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: Postresql 8.0 Beta 3 - SELECT ... FOR UPDATE
Список pgsql-hackers
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...

-- 



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: plpgsql lacks generic identifier for record in triggers...
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Postresql 8.0 Beta 3 - SELECT ... FOR UPDATE