Re: timeout implementation issues

Tom Lane wrote:
> Jan Wieck <janwieck(at)yahoo(dot)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(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