From: | "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Tatsuo Ishii" <t-ishii(at)sra(dot)co(dot)jp> |
Cc: | <JanWieck(at)Yahoo(dot)com>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | RE: PL/pgSQL bug? |
Date: | 2001-08-12 15:08:48 |
Message-ID: | EKEJJICOHDIEMGPNIFIJAENMFBAA.Inoue@tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | gabriel | 2001-08-12 15:27:55 | CREATE USER in a TRIGGER |
Previous Message | Peter Eisentraut | 2001-08-12 10:50:57 | Re: Initdb -E LATIN1 fails when no multibyte support compiled in (current CVS) |