Re: timeout implementation issues

Bruce Momjian wrote:
> 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.
   I  have to agree with Tom here. It's not right to hack up SET   to be accepted in transaction abort state. Nor is it
rightto   queue  up  SET  requests  then. If those queued SET's lead to   errors, when do you report them? On
ROLLBACK?
   If at all, SET commands should behave like  everything  else.   If done inside a transaction, they have to
rollback.

> > > 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.
   Could  we  get  out  of  this  by  defining that "timeout" is   automatically reset at next statement end? So that
theentire   thing is
 
       SET timeout=4;       SELECT ...;       -- We're back in no-timeout
   And  that it doesn't matter if we're in a transaction, if the   statement aborts, yadda yadda...


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #