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

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

From: Gaetano Mendola <mendola(at)bigfoot(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: BUG #1231: Probelm with transactions in stored code.
Date: 2004-08-26 08:23:33
Message-ID: 412D9E05.9070408@bigfoot.com (view raw or flat)
Thread:
Lists: pgsql-bugs
Tom Lane wrote:

 > Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> writes:
 >
 >>I believe it sees the one that was valid in the snapshot as of the
 >>beginning of the function.
 >
 >
 > Actually, the problem is that it can see *both* that row and the updated
 > row; it's a crapshoot which one will be returned by the SELECT INTO.

Confirmed, if the last select is:

select count(*) into a from test where id=1;

this return 2. There is a space for a new bug considering that if the
table have the unique index on id that select must return 1.

 > The reason this can happen is that we're not doing SetQuerySnapshot
 > between commands of a plpgsql function.  There is discussion going way
 > way back about whether we shouldn't do so (see the archives).  I think
 > the major reason why we have not done it is fear of introducing
 > non-backwards-compatible behavior.  Seems like 8.0 is exactly the right
 > version to consider doing that in.

If my 2 cents are valid I agree with you, what I don't totally agree is why
consider this bug as a *feature* in previous 8.0 version.


Regards
Gaetano Mendola





In response to

Responses

pgsql-bugs by date

Next:From: Robert TreatDate: 2004-08-26 12:27:35
Subject: Re: BUG #1231: Probelm with transactions in stored code.
Previous:From: andrea.martanoDate: 2004-08-26 08:19:23
Subject: Postgres 8.0.0b1 build on Solaris 10 Ultrasparc

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