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.
This argument holds no water. On what will you base your estimate of
a good value for lock_timeout? It is nothing more than your estimate
of the statement runtime for some other backend that is currently
holding the lock you want ... an estimate which surely has less, not
more, reliability than the estimate you could make of the maximum
runtime of your own statement, because you have less information about
just what that other backend is doing. (And both you and the other
backend are in turn dependent on waiting for locks held by third
parties, etc etc.)
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.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
