Re: timeout implementation issues

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

In response to

Responses

Browse pgsql-hackers by date

  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