Re: PL/pgSQL bug?
От | Hiroshi Inoue |
---|---|
Тема | Re: PL/pgSQL bug? |
Дата | |
Msg-id | 3B7AF460.B822BC8@tpf.co.jp обсуждение исходный текст |
Ответ на | Re: PL/pgSQL bug? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane wrote: > > "Hiroshi Inoue" <Inoue@tpf.co.jp> writes: > > It's possible for a function to use a unique snapshot > > if there are only SELECT statements in the function > > but it's impossible if there are UPDATE/DELETE or > > SELECT .. FOR UPDATE statements etc. > > You are confusing snapshots (which determine visibility of the results > of OTHER transactions) Please note that the meaning of snapshots for statements other than SELECT is different from that for SELECT. For example, 1) The result of SELECT .. FOR UPDATE may be different from that of SELECT for the same snapshot. 2) Once a snapshot given, the result of SELECT is dicisive but that of SELECT .. FOR UPDATE isn't. SELECT and SELECT .. FOR UPDATE are alike in appearance but quite different in nature. There's no real snapshot for SELECT .. FOR UPDATE in the current implementation. I suggested the implementation with the real snapshot (without the word snapshot though) once before 6.5. The implementation seems hard and the possibility isn't confirmed. Even though the implementation is possible, it requires the repeated computation of snapshot until the consisteny is satisfied, and so arbitrary snapshots aren't allowed. There's little meaning for SELECT statements and subsequent other statements like UPDATE/DELETE/SELECT .. FOR UPDATE to use the same snapshot in read committed mode. There's no consistency with the current handling of snapshots inside a function call. regards, Hiroshi Inoue
В списке pgsql-hackers по дате отправления: