Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-bugs by date

Next:From: C├ęsar ArnoldDate: 2004-08-26 02:14:35
Subject: Re: replacing a function called "isnull" reports an error
Previous:From: Bruce MomjianDate: 2004-08-26 01:49:20
Subject: Re: Inconsistent pg_ctl behaviour: start vs. runservice

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group