Re: timeout implementation issues - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: timeout implementation issues
Date
Msg-id 200204181434.g3IEYp304024@candle.pha.pa.us
Whole thread Raw
In response to Re: timeout implementation issues  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: timeout implementation issues  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > I have added this to the TODO list, with a question mark.  Hope this is
> > OK with everyone.
> 
> >         o Abort SET changes made in aborted transactions (?)
> 
> Actually, I was planning to make only search_path act that way, because
> of all the push-back I'd gotten on applying it to other SET variables.
> search_path really *has* to have it, but if there's anyone who agrees
> with me about doing it for all SET vars, they didn't speak up :-(

Woh, this all started because of timeout, which needs this fix too.  We
certainly need something and I don't want to get into on of those "we
can't all decide, so we do nothing" situations.

I have updated the TODO to:
   o Abort all or commit all SET changes made in an aborted transaction    

I don't think our current behavior is defended by anyone.  Is abort all
or commit all the only two choices?   If so, we will take a vote and be
done with it.

--  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
 


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: timeout implementation issues
Next
From: Michael Loftis
Date:
Subject: Re: Index Scans become Seq Scans after VACUUM ANALYSE