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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Treat | 2004-08-26 12:27:35 | Re: BUG #1231: Probelm with transactions in stored code. |
Previous Message | andrea.martano | 2004-08-26 08:19:23 | Postgres 8.0.0b1 build on Solaris 10 Ultrasparc |