Am Mittwoch, 11. Januar 2006 22:33 schrieb Tom Lane:
> I suppose though that there's some chance of the constant-argument case
> being treated differently from not-constant, so your idea has some merit.
Use a global rather than a local variable.
--
Peter Eisentraut
http://developer.postgresql.or
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Mittwoch, 11. Januar 2006 22:33 schrieb Tom Lane:
>> I suppose though that there's some chance of the constant-argument case
>> being treated differently from not-constant, so your idea has some merit.
> Use a global rather than a local variable.
--- 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
Or maybe, if it is really too smart (able to compute the result at compile
time), we could have not to use a constant argument. Something like 'return
finite((double)argv) ? 0 : 1'.
---(end of broadcast)---
TIP 1: if posting/reading through Usenet
Thanks for your suggestion. It could have been the include files but I
recompiled gcc on the system and it didn't change anything. Actually, I found
the solution when I tried to understand why configure detects a finite()
function on a system which does not have it.
First, I checked that there
> In principle an aggressive compiler could still determine that the
> global variable is modified nowhere else in the executable.
Yes, it can determine that the variable content is constant but what is
important here is that it cannot determine its value at compile time. This way,
either it repla
I will also try these tests with '-O2' tomorrow (compile conftest and look if
the symbol is still inside). I will even try more aggressive optimization.
De : Tom Lane [mailto:[EMAIL PROTECTED]
Bruce Momjian writes:
> Could any other configure tests fail in this way?
Good point. The isinf() te
Am Donnerstag, 12. Januar 2006 09:57 schrieb Tom Lane:
> In principle an aggressive compiler could still determine that the
> global variable is modified nowhere else in the executable.
I think to do that the compiler would have to prove what the dynamic linker
will do at run time.
> I did like
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.
>
>
> 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
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Donnerstag, 12. Januar 2006 09:57 schrieb Tom Lane:
>> In principle an aggressive compiler could still determine that the
>> global variable is modified nowhere else in the executable.
> I think to do that the compiler would have to prove what the
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 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
13 matches
Mail list logo
