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  (Stephan Szabo <sszabo@megazone.bigpanda.com>)
Список 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 по дате отправления:

Предыдущее
От: Joe Conway
Дата:
Сообщение: Re: TODO items
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: TODO items