> > It is not something that makes anything unrelyable or less robust.
>
> How can you argue that? The presence of a lock timeout *will* make
> operations fail that otherwise would have succeeded; moreover that
> failure will be pretty unpredictable (at least from the point of view
> of the app
> > The timeout will be useful to let the client or user decide
> > on an alternate course of action other that killing his
> > application (without the need for timers or threads in the
> > client program).
>
> This assumes (without evidence) that the client has a good
> idea of what the timeout
> > The timeout will be useful to let the client or user decide on an
> > alternate course of action other that killing his application (without
> > the need for timers or threads in the client program).
>
> This assumes (without evidence) that the client has a good idea of what
> the timeout li
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> The timeout will be useful to let the client or user decide on an
> alternate course of action other that killing his application (without
> the need for timers or threads in the client program).
This assumes (without evidence) that the client
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> The timeout will be useful to let the client or user decide on an
> alternate course of action other that killing his application (without
> the need for timers or threads in the client program).
Okay, let's take a close look at this assumptio
> > Added to TODO:
> > * Add SET parameter to timeout if waiting for lock too long
>
> I repeat my strong objection to any global (ie, affecting all locks)
> timeout. Such a "feature" will have unpleasant consequences.
Except that other people like myself, see those consequences
as a plea
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Added to TODO:
> > > * Add SET parameter to timeout if waiting for lock too long
> >
> > I repeat my strong objection to any global (ie, affecting all locks)
> > timeout. Such a "feature" will have unpleasant consequences.
>
> I envisioned:
> > I envisioned:
>
> > SET TIMEOUT TO 10;
> > UPDATE tab SET col = 3;
> > RESET TIMEOUT
>
> > Can't we get that work work properly? Let the timeout only
> apply to the
> > 'tab' table and none of the others.
>
> As Henryk has implemented it, it WON'T only apply to the 'tab' tabl
