From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jan Wieck <janwieck(at)yahoo(dot)com> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Jessica Perry Hekman <jphekman(at)dynamicdiagrams(dot)com>, Barry Lind <barry(at)xythos(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: timeout implementation issues |
Date: | 2002-04-05 19:13:26 |
Message-ID: | 2284.1018034006@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 2002-04-05 19:22:02 | Re: timeout implementation issues |
Previous Message | Dann Corbit | 2002-04-05 19:04:13 | Suggestion for optimization |