"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,
>
> > 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
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
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 w
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 timeo
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 you
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 q
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 i
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
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
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 k
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 PROTEC
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
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 fu
Satoshi Nagayasu <[EMAIL PROTECTED]> writes:
> When a transaction is blocked by another transaction because of
> waiting a lock, we need a lock timeout in some cases.
Isn't there an existing solution for this problem?
regards, tom lane
---(end of b
Hello all,
I've created a lock timeout patch and it's attached.
When a transaction is blocked by another transaction because of
waiting a lock, we need a lock timeout in some cases.
Using this patch, the lock timeout is enabled with
'lock_timeout = ' directive in postgresql.conf,
and if a ti
16 matches
Mail list logo
