Re: BUG #1231: Probelm with transactions in stored code.

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.

In response to

Responses

Browse pgsql-bugs by date

  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