Re: PL/pgSQL bug?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>
Cc: Inoue(at)tpf(dot)co(dot)jp, JanWieck(at)Yahoo(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: PL/pgSQL bug?
Date: 2001-08-13 02:17:31
Message-ID: 1872.997669051@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> writes:
> BTW, why must we restore the previous QuerySnapshot? We already break
> the rule (if it's a rule).

No we don't. There are no SetQuerySnapshot calls occuring *within*
a query. An example of why that would be unacceptable: consider

select myfunc(f1) from table where f2 = 42;

Suppose executing myfunc() causes an unrestored SetQuerySnapshot call.
Then, if other transactions are busy changing f2 values, the set of
rows that this query returns could depend on the order in which rows
are visited --- since whether it thinks a row with f2 = 42 is visible
might depend on whether any previous rows had been matched (causing
myfunc() to be evaluated). For that matter, it could depend on the
form of the query plan used --- in some plans, myfunc() might be called
while the scan is in progress, in others not till afterward.

> For example, COPY TO calls SetQuerySnapshot
> (see tcop/utility.c).

That's just because postgres.c doesn't do it automatically for utility
statements. There's still just one SetQuerySnapshot per query.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Vince Vielhaber 2001-08-13 02:21:55 Re: Re: [PATCHES] Select parser at runtime
Previous Message Tom Lane 2001-08-13 02:06:43 Re: [JDBC] JDBC pg_description update needed for CVS tip