From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Mendola Gaetano" <mendola(at)bigfoot(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: consistency check on SPI tuple count failed |
Date: | 2003-08-08 17:02:25 |
Message-ID: | 28162.1060362145@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Mendola Gaetano" <mendola(at)bigfoot(dot)com> 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?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2003-08-08 17:09:38 | Re: TODO items |
Previous Message | Joe Conway | 2003-08-08 17:01:46 | Re: TODO items |