Re: timeout implementation issues

Tom Lane wrote:
> Jan Wieck <janwieck@yahoo.com> writes:
> >     If at all, SET commands should behave like  everything  else.
> >     If done inside a transaction, they have to rollback.
> 
> I have thought of a scenario that may be sufficient to justify fixing
> SETs to roll back on transaction abort.  Consider
> 
> 	BEGIN;
> 
> 	CREATE SCHEMA foo;
> 
> 	SET search_path = 'foo, public';
> 
> 	ROLLBACK;
> 
> As the code stands, this will leave you with an invalid search path.
> (What's worse, if you now execute CREATE TABLE, it will happily create
> tables belonging to the vanished namespace foo.  Everything will seem
> to work fine ... until you try to find those tables again in a new
> session ...)
> 
> It seems clear to me that SET *should* roll back on abort.  Just a
> matter of how important is it to fix.

That was my point, that having SET work pre-abort and ignored post-abort
is broken itself, whether we implement timeout or not.  Before we had
tuple-reading SET variables, it probably didn't matter, but now with
schemas, I can see it is more of an issue.

-- 
  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, Pennsylvania 19026