On Tue, Jun 29, 2004 at 09:25:27 +0900,
Satoshi Nagayasu [EMAIL PROTECTED] wrote:
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.
Why not set statement timeout low
Tom,
I'd accept a mechanism to enforce a timeout at the lock level if you
could show me a convincing use-case for lock timeouts instead of
statement timeouts, but I don't believe there is one. I think this
proposal is a solution in search of a problem.
Hmmm ... didn't we argue this out with
On Tue, 2004-06-29 at 18:36, Josh Berkus wrote:
Tom,
I'd accept a mechanism to enforce a timeout at the lock level if you
could show me a convincing use-case for lock timeouts instead of
statement timeouts, but I don't believe there is one. I think this
proposal is a solution in search
Tom,
I'd accept a mechanism to enforce a timeout at the lock level if you
could show me a convincing use-case for lock timeouts instead of
statement timeouts, but I don't believe there is one. I think this
proposal is a solution in search of a problem.
Hmmm ... didn't we argue this
Merlin Moncure [EMAIL PROTECTED] writes:
FWIW, I think the treatment of locking in the docs could use some
improvement. Especially wrt MVCC and pessimistic locking and the 'big
picture' issues going on there (especially why the former is better than
the latter).
Send a patch ...
Tom Lane wrote:
I'd accept a mechanism to enforce a timeout at the lock level if you
could show me a convincing use-case for lock timeouts instead of
statement timeouts, but I don't believe there is one. I think this
proposal is a solution in search of a problem.
I think statement_timeout
On Mon, 28 Jun 2004, Satoshi Nagayasu 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
On Mon, 2004-06-28 at 02:16, Satoshi Nagayasu wrote:
Tom Lane wrote:
I'd accept a mechanism to enforce a timeout at the lock level if you
could show me a convincing use-case for lock timeouts instead of
statement timeouts, but I don't believe there is one. I think this
proposal is a
Robert Treat wrote:
I think statement_timeout and lock_timeout are different.
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.
How
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
Tom,
I guess the transaction cancellation from the client
using PQrequestCancel() is available, but the cancellation
logic must be implemented in the client-application using
signal or thread.
I think detecting such situation on server-side is not
available now, and SQL Server or DB2 have same
Satoshi Nagayasu [EMAIL PROTECTED] writes:
I guess the transaction cancellation from the client
using PQrequestCancel() is available, but the cancellation
logic must be implemented in the client-application using
signal or thread.
Actually I think the recommended solution involves using
statement_timeout terminates large sort or scan
even if it is running, doesn't it?
statement_timeout doesn't care that
the process is waiting a lock or running.
I don't want to terminate a running query.
So a lock waiting backend shold be killed.
Tom Lane wrote:
Satoshi Nagayasu [EMAIL
Satoshi Nagayasu [EMAIL PROTECTED] writes:
statement_timeout terminates large sort or scan
even if it is running, doesn't it?
statement_timeout doesn't care that
the process is waiting a lock or running.
I don't want to terminate a running query.
So a lock waiting backend shold be killed.
14 matches
Mail list logo
