Re: timeout implementation issues
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jan Wieck <janwieck@yahoo.com>
Cc: Bruce Momjian <pgman@candle.pha.pa.us>, Jessica Perry Hekman <jphekman@dynamicdiagrams.com>, Barry Lind <barry@xythos.com>, pgsql-hackers@postgresql.org
Date: 2002-04-05T19:13:26Z
Lists: pgsql-hackers
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. regards, tom lane