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?  (Tatsuo Ishii <t-ishii@sra.co.jp>)
RE: PL/pgSQL bug?  ("Hiroshi Inoue" <Inoue@tpf.co.jp>)
Re: PL/pgSQL bug?  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Initdb -E LATIN1 fails when no multibyte support compiled in (current CVS)
Следующее
От: "gabriel"
Дата:
Сообщение: CREATE USER in a TRIGGER