On Fri, 8 Aug 2003, Tom Lane wrote: > "Mendola Gaetano" <[EMAIL PROTECTED]> writes: > > Again the error: > > > kalman=# select bar(); > > ERROR: consistency check on SPI tuple count failed > > CONTEXT: PL/pgSQL function "bar" line 5 at for over select rows > > kalman=# select bar(); > > ERROR: consistency check on SPI tuple count failed > > CONTEXT: PL/pgSQL function "bar" line 5 at for over select rows > > server closed the connection unexpectedly > > This probably means the server terminated abnormally > > before or while processing the request. > > The connection to the server was lost. Attempting reset: Failed. > > After adding a second row to the test table, I am able to reproduce > the above (including the core dump after second try) on an intel/linux > box, but *not* on HPUX. > > I now suspect a memory-stomp kind of problem, like someone writing one > too many bytes in a struct. HPUX tends to mask these in situations > where intel will not, because it uses MAXALIGN 8 rather than 4. > > 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. ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
