Re: consistency check on SPI tuple count failed
От | Stephan Szabo |
---|---|
Тема | Re: consistency check on SPI tuple count failed |
Дата | |
Msg-id | 20030808112122.R75184-100000@megazone.bigpanda.com обсуждение исходный текст |
Ответ на | Re: consistency check on SPI tuple count failed (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: consistency check on SPI tuple count failed
|
Список | pgsql-hackers |
On Fri, 8 Aug 2003, Tom Lane wrote: > "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? 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.
В списке pgsql-hackers по дате отправления: