Re: timeout implementation issues

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026