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