Tom Lane wrote:
>Andrew Sullivan <andrew@libertyrms.info> writes:
>
>
>>On Tue, Sep 17, 2002 at 04:25:45PM +0200, Wim wrote:
>>
>>
>>>ERROR: AllocSetFree: cannot find block containing chunk 4c5ad0
>>>
>>>Postgres is running on solaris 8...
>>>
>>>
>
>
>
>>Someone else suggested that this would not be the error when you have
>>written bad data to the disk (I thought you could have this if the
>>controller was flakey and wrote bad data in the past. Maybe I'm
>>wrong. Probably).
>>
>>
>
>Actually, what it looks like to me is a memory clobber; I don't think
>bad data on disk would be likely to lead to this particular type of
>failure. But writing one byte too many into a string, and thereby
>zeroing the high-order byte of an adjacent pointer, could lead to
>exactly this message when we later try to pfree() the pointer.
>
>I am wondering if Wim is running into that same Solaris snprintf() bug
>that we discovered awhile back --- it was not clear if the bug still
>exists in Solaris 8, but the symptoms sure match. See
>http://archives.postgresql.org/pgsql-bugs/2002-07/msg00059.php
>
>It would be useful to see a stack traceback from the point of the error,
>if possible.
>
> regards, tom lane
>
I Would like to send a stack traceback, but I need some halp on this
(never done this before).
some add. info:
SELECT relname FROM pg_class WHERE relname like 'pg_%' AND relkind = 'r';
gives:
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.
SELECT relname FROM pg_class;
works well...
SELECT relname, relkind from pg_class WHERE relkind='r';
works also...
SELECT relname, relkind from pg_class WHERE relname like 'pg_%';
produces the same error as above...
>
>---------------------------(end of broadcast)---------------------------
>TIP 5: Have you checked our extensive FAQ?
>
>http://www.postgresql.org/users-lounge/docs/faq.html
>
>
>
>
Cheers!
Wim