Re: consistency check on SPI tuple count failed
От | Tom Lane |
---|---|
Тема | Re: consistency check on SPI tuple count failed |
Дата | |
Msg-id | 28162.1060362145@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: consistency check on SPI tuple count failed ("Mendola Gaetano" <mendola@bigfoot.com>) |
Ответы |
Re: consistency check on SPI tuple count failed
|
Список | pgsql-hackers |
"Mendola Gaetano" <mendola@bigfoot.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
В списке pgsql-hackers по дате отправления: