Tatsuo Ishii <t-ishii@sra.co.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
