From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> |
Cc: | Mendola Gaetano <mendola(at)bigfoot(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: consistency check on SPI tuple count failed |
Date: | 2003-08-08 19:05:13 |
Message-ID: | 29030.1060369513@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> writes:
> On Fri, 8 Aug 2003, Tom Lane wrote:
>> I have also just traced through _SPI_cursor_operation() in spi.c,
>> watched PortalRunFetch return 2, and then watched _SPI_checktuples read
>> zero from _SPI_current->processed. How the heck could that happen?
>> Compiler bug, or am I just crazy?
> Not sure, but I got the same thing. When I changed it to put the
> result in a temporary int variable and then put it in it started
> working for me (returning 0), reverting to the original made it fail
> again. I'm going to try -O0 and see what happens there.
Oooohhhh ...
<lightbulb>
SPI_stack can move around as functions are entered/exited.
</lightbulb>
Wonder why we've not seen that kind of failure happen before? Someone
(doubtless me) must have changed the coding of this routine since 7.3.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Larry Rosenman | 2003-08-08 19:12:39 | Re: build on unixware 713 |
Previous Message | Andrew Dunstan | 2003-08-08 19:02:47 | Re: build on unixware 713 |