Re: timeout implementation issues

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Yes, I now think that saving the SET commands that are ignored in a
> > transaction and running them _after_ the transaction completes may be
> > the best thing.
> 
> No, that's just plain ridiculous.  If you want to change the semantics

No more ridiculous than what we have now.

> of SET, then make it work *correctly*, viz like an SQL statement: roll
> it back on transaction abort.  Otherwise leave it alone.

I am not going to leave it alone based only on your say-so, Tom.

> > If we don't somehow get this to work, how do we do timeouts, which we
> > all know we should have?
> 
> This is utterly unrelated to timeouts.  With or without any changes in
> SET behavior, JDBC would need to issue a SET after completion of the
> transaction if they wanted to revert a query_timeout variable to the
> no-timeout state.

"Utterly unrelated?"  No.  If we can get SET to work properly in
transactions, jdbc can cleanly issue SET timeout=4, statement, SET
timeout=0.  Without it, using SET for timeout is a problem.  That's how
we got to this issue in the first place.

I am still looking for a constructive idea on how we can get this to
work, rather than calling my ideas "ridiculous".

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026