Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Rod Taylor wrote:
> >> 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...
>
> > Wouldn't a LOCK NOWAIT be a
On Wed, 2004-11-24 at 22:47 -0500, Bruce Momjian wrote:
> Rod Taylor wrote:
> > 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.
> >
> > Ac
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Rod Taylor wrote:
>> 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...
> Wouldn't a LOCK NOWAIT be a better solution? That is new
Rod Taylor wrote:
> 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 processe
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. D
ronzo wrote:
> Hi
>
> Was already implemented the timeout on the "SELECT ... FOR UPDATE"
> (non-blocking lock) and/or is possible known if the lock exist on the
> specified ROW before executing the SELECT?
>
> Please note: ours need is the timeout/verify at the ROW level, not at the
> table le
There is a statement_timeout that will control how long a statement can
execute before being cancelled. We have never agreed that controlling
how long we wait for an individual lock is valuable.
---
Robert Treat wrote:
> On
On Thursday 21 October 2004 06:44, you wrote:
> Hi
>
> Was already implemented the timeout on the "SELECT ... FOR UPDATE"
> (non-blocking lock) and/or is possible known if the lock exist on the
> specified ROW before executing the SELECT?
>
No.
> Please note: ours need is the timeout/verify at th
