I wrote:
> It looks to me like the correct test requires passing in the current
> command ID so we can check the tuple's cmax against it.
Er, cmin not cmax. Here's the patch against 8.1 if you need it.
regards, tom lane
Index: src/backend/commands/trigger.c
I wrote:
> I think EvalPlanQual is deciding that updated tuples are valid in
> some cases where it shouldn't. Unfortunately, if that's correct it
> means that all the branches are broken since last August :-(
OK, here's the deal: the former coding of EvalPlanQual ignored (returned
NULL for) any t
>
> I think EvalPlanQual is deciding that updated tuples are valid in
> some cases where it shouldn't. Unfortunately, if that's correct it
> means that all the branches are broken since last August :-(
>
>regards, tom lane
>
i reproduced it in 8.1.1, so i guess you are rig
Euler Taveira de Oliveira <[EMAIL PROTECTED]> writes:
> Sorry for that. I didn't have the data yet. Some data to test it is in:
> http://www.timbira.com/tst2.sql.gz
Thanks.
> In 8.0 and previous I didn't reproduce it.
Which versions did you try exactly? I've reproduced it in 8.0.6 and HEAD.
>
--- Tom Lane <[EMAIL PROTECTED]> escreveu:
> "Euler Taveira de Oliveira" <[EMAIL PROTECTED]> writes:
> > I just execute the same transaction in 2 different backends and I
> got the
> > message: 'attempted to update invisible tuple'.
>
> If you want this investigated then you'll need to provide a
"Euler Taveira de Oliveira" <[EMAIL PROTECTED]> writes:
> I just execute the same transaction in 2 different backends and I got the
> message: 'attempted to update invisible tuple'.
If you want this investigated then you'll need to provide a
self-contained example. We have other things to do than
The following bug has been logged online:
Bug reference: 2166
Logged by: Euler Taveira de Oliveira
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1+
Operating system: Slackware 10.1
Description:attempted to update invisible tuple
Details:
I just execute the