From: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> |
---|---|
To: | Gaetano Mendola <mendola(at)bigfoot(dot)com> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #1231: Probelm with transactions in stored code. |
Date: | 2004-08-26 02:14:25 |
Message-ID: | 20040825191237.X6393@megazone.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Thu, 26 Aug 2004, Gaetano Mendola wrote:
> Stephan Szabo wrote:
>
> > On Wed, 25 Aug 2004, PostgreSQL Bugs List wrote:
> >
> > Actually, it shows that functions have odd behavior when locking is
> > involved (your statement would potentially be true if you could replicate
> > this without the functions). IIRC, there are issues currently with which
> > rows you see in such functions unless you end up using FOR UPDATE on the
> > selects or something of that sort.
>
> If the first select is a "FOR UPDATE" nothing change. For sure the last select in
Right, I changed both to see if that made it "work" for me and it did. I
didn't bother to try the only after one.
> that function doesn't see the same row if you perform that same select after
> the function execution, and for sure doesn't see the same row that the update
> statement touch.
I believe it sees the one that was valid in the snapshot as of the
beginning of the function.
From | Date | Subject | |
---|---|---|---|
Next Message | César Arnold | 2004-08-26 02:14:35 | Re: replacing a function called "isnull" reports an error |
Previous Message | Bruce Momjian | 2004-08-26 01:49:20 | Re: Inconsistent pg_ctl behaviour: start vs. runservice |