Re: timeout implementation issues

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
Cc: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Peter Eisentraut" <peter_e(at)gmx(dot)net>, "Jessica Perry Hekman" <jphekman(at)dynamicdiagrams(dot)com>, "Jan Wieck" <janwieck(at)yahoo(dot)com>, "Barry Lind" <barry(at)xythos(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: timeout implementation issues
Date: 2002-04-08 17:09:44
Message-ID: 21727.1018285784@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> writes:
> Sorry for my poor explanation. What I meant is that *Rollback*
> is to cancel the changes made to SQL-data or schemas
> not to put back the variables which are local to the session.

Uh, why? Seems to me you are asserting as a given exactly the
point that is under debate. Let me give a counterexample:

BEGIN;
CREATE TEMP TABLE foo;
something-erroneous;
END;

The creation of the temp table will be rolled back on error, no?
Now the temp table is certainly session local --- ideally our
implementation would not let any other session see any trace of
it at all. (In practice it is visible if you know where to look,
but surely that's just an implementation artifact.)

If you argue that SETs should not roll back because they are
session-local, it seems to me that a logical consequence of that
position is that operations on temp tables should not roll back
either ... and that can hardly be deemed desirable.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hiroshi Inoue 2002-04-08 17:17:54 Re: What's the CURRENT schema ?
Previous Message Tom Lane 2002-04-08 17:03:41 Re: timeout implementation issues