Re: lock timeout patch

Поиск
Список
Период
Сортировка
От Satoshi Nagayasu
Тема Re: lock timeout patch
Дата
Msg-id 40E0B6F7.30104@noanet06.noanet.nttdata.co.jp
обсуждение исходный текст
Ответ на Re: lock timeout patch  (Dennis Bjorklund <db@zigo.dhs.org>)
Ответы Re: lock timeout patch  (Bruno Wolff III <bruno@wolff.to>)
Список pgsql-hackers
Dennis Bjorklund wrote:
>>If I set statement_timeout to 1000 to detect a lock timeout,
>>I can't run a query which takes over 1 sec.
>>
>>If a lock wait is occured, I want to detect it immediately,
>>but I still want to run a long-running query.
> 
> 
> Why is it important what it is that makes your query not return as fast as
> you expect? Maybe it's locking, maybe the computer is swapping, maybe it's
> just lack of IO to that disk that holds the table, maybe it does a big
> sort and have too little sort_mem to do it fast, ...
> 
> What makes locking special?

Processing slow-down is just a hardware/software sizing issue.
Of course we need to fix it when a problem is occured,
but I think it's a different kind of problem.

In large databases, such as DSS(decision support system),
some queries takes one or more minutes. I think it's okey.

But I don't want to wait one or more minutes just for a lock.
I need to return a message to the user "retry later." or
something like that. It depends on various applications.

So I think detecting a lock waiting is important.

-- 
NAGAYASU Satoshi <nagayasus@nttdata.co.jp>


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

Предыдущее
От: Satoshi Nagayasu
Дата:
Сообщение: Re: lock timeout patch
Следующее
От: Christopher Kings-Lynne
Дата:
Сообщение: client_min_messages in dumps?