Re: PL/pgSQL bug?
От | Tom Lane |
---|---|
Тема | Re: PL/pgSQL bug? |
Дата | |
Msg-id | 1872.997669051@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | RE: PL/pgSQL bug? (Tatsuo Ishii <t-ishii@sra.co.jp>) |
Ответы |
Re: PL/pgSQL bug?
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: