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 по дате отправления: