[ Charset ISO-8859-1 unsupported, converting... ]
> > This is the real reason why I've been holding out for restricting the
> > feature to a specific LOCK TABLE statement: if it's designed that way,
> > at least you know which lock you are applying the timeout to, and have
> > some chance of being
> One idea Tom had was to make it only active in a transaction,
> so you do:
>
> BEGIN WORK;
> SET TIMEOUT TO 10;
> UPDATE tab SET col = 3;
> COMMIT
>
> Tom is concerned people will do the SET and forget to RESET
> it, causing all queries to be affected by the timeout.
> This is the real reason why I've been holding out for restricting the
> feature to a specific LOCK TABLE statement: if it's designed that way,
> at least you know which lock you are applying the timeout to, and have
> some chance of being able to estimate an appropriate timeout.
As I pointed be
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> 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
> > 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.
But LOCK TABLE T IN ROW EXCLUSIVE MODE WITH TIMEOUT X will not give
requ
Michael Ansley <[EMAIL PROTECTED]> writes:
> Sorry for my forgetfulness (and a search through geocrawler didn't turn up
> anything useful), but what was the problem with something like NOWAIT?
> e.g.: SELECT * FROM a FOR UPDATE NOWAIT;
> where, if the required lock could not be obtained immediatel
Title: RE: AW: [HACKERS] timeout on lock feature
Sorry for my forgetfulness (and a search through geocrawler didn't turn up anything useful), but what was the problem with something like NOWAIT?
e.g.: SELECT * FROM a FOR UPDATE NOWAIT;
where, if the required lock could not be obt
Bruce Momjian <[EMAIL PROTECTED]> writes:
> 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
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.
regards, tom l
Added to TODO:
* Add SET parameter to timeout if waiting for lock too long
>
> > I was thinking SET because UPDATE does an auto-lock.
>
> Optimal would imho be a SET that gives a maximum amount of time in seconds
> the client is willing to wait for any lock. But I
10 matches
Mail list logo
