RE: PL/pgSQL bug?
От | Hiroshi Inoue |
---|---|
Тема | RE: PL/pgSQL bug? |
Дата | |
Msg-id | EKEJJICOHDIEMGPNIFIJAENMFBAA.Inoue@tpf.co.jp обсуждение исходный текст |
Ответ на | Re: PL/pgSQL bug? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
RE: PL/pgSQL bug?
RE: PL/pgSQL bug? Re: PL/pgSQL bug? |
Список | pgsql-hackers |
> -----Original Message----- > From: Tom Lane > > I believe the reason for this is that in Read Committed mode, > each separate query from the client computes a new snapshot (see > SetQuerySnapshot calls in postgres.c). So, when your > "select ctid, i from t1" query executes, it computes a snapshot > that says T1 is committed, and then it doesn't see the row left > over from T1. On the other hand, your plpgsql function operates > inside a single client query and so it's using just one QuerySnaphot. > > One way to make the results equivalent is to compute a new QuerySnapshot > for each SPI query. Quite aside from the cost of doing so, I do not > think it makes sense, considering that the previous QuerySnapshot must > be restored when we return from the function. Do we really want > functions to see transaction status different from what's seen outside > the function call? Yes I do. > I doubt it. > > The other way to make the results the same is to omit the > SetQuerySnapshot calls for successive client-issued queries in one > transaction. What's different from SERIALIZABLE mode ? regards, Hiroshi Inoue
В списке pgsql-hackers по дате отправления: