Re: MemoryContextAlloc: invalid request size

From: "Brusser, Michael" <Michael(dot)Brusser(at)matrixone(dot)com>
To: "'Pgsql-Hackers (pgsql-hackers(at)postgresql(dot)org)'" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: MemoryContextAlloc: invalid request size
Date: 2005-06-17 19:57:22
Message-ID: 9150DCE0CCB4D411A7DB00508BB0DBF21031E4C8@msx1am.matrixone.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I got the copy of the database and ran it with truss.

From the trace log it looked like
${PGDATA/}base/<last-number>/pg_internal.init was corrupted

I replaced this file with ${PGDATA/}base/<prev-number>/pg_internal.init

After that I was able to login and use database. Still don't understand what
I've done.

Can somebody shed little light on what actually happened?

Thanks,

Mike

_____

From: Brusser, Michael [mailto:Michael(dot)Brusser(at)matrixone(dot)com]
Sent: Thursday, June 16, 2005 8:28 PM
To: 'Pgsql-Hackers (pgsql-hackers(at)postgresql(dot)org)'
Subject: [HACKERS] MemoryContextAlloc: invalid request size

Our customer is reporting a database problem after they ran into a
disk quota/filesystem full situation.

This is Postgres 7.2.x on Solaris.
The database server starts without any obvious errors, but the app. Server
cannot establish connection. (It is setup to use Unix Domain Socket)

I did not have a chance to see the database-log, but we have the error-log
and
the truss log from the App. Server.

In the error-log I see this:
... ...
Connection to database failed
FATAL: MemoryContextAlloc: invalid request size 0

And this in the trace log:
... ...
10894: open("/usr/lib/libresolv.so.2", O_RDONLY) = 11
10894: fstat(11, 0xFFBE9004) = 0
10894: mmap(0xFE020000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED,
11, 0) = 0xFE020000
10894: mmap(0x00000000, 303104, PROT_READ|PROT_EXEC, MAP_PRIVATE, 11, 0) =
0xFDD20000
10894: mmap(0xFDD64000, 15564, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED, 11, 212992) = 0xFDD64000
10894: mmap(0xFDD68000, 2728, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_ANON, -1, 0) = 0xFDD68000
10894: munmap(0xFDD54000, 65536) = 0
10894: memcntl(0xFDD20000, 33536, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
10894: close(11) = 0
10894: munmap(0xFE020000, 8192) = 0
10894: so_socket(1, 2, 0, "", 1) = 11
10894: fstat64(11, 0xFFBE8A70) = 0
10894: getsockopt(11, 65535, 8192, 0xFFBE8B70, 0xFFBE8B6C, 0) = 0
10894: setsockopt(11, 65535, 8192, 0xFFBE8B70, 4, 0) = 0
10894: fcntl(11, F_SETFL, 0x00000080) = 0
10894: connect(11, 0x0060EAA0, 77, 1) = 0
10894: poll(0xFFBE89E8, 1, -1) = 1
10894: sigaction(SIGPIPE, 0xFFBE8788, 0xFFBE8888) = 0
10894: send(11, "\0\001 (\002\0\0 s y n c".., 296, 0) = 296
10894: sigaction(SIGPIPE, 0xFFBE8788, 0xFFBE8888) = 0
10894: poll(0xFFBE89E8, 1, -1) = 1
10894: recv(11, " R\0\0\0\0 E F A T A L :".., 16384, 0) = 58
... ...

Could you recommend the remedy?

Thanks in advance,
Mike.

Browse pgsql-hackers by date

  From Date Subject
Next Message Dave Page 2005-06-17 20:11:57 Re: Utility database
Previous Message Dave Page 2005-06-17 19:56:15 Re: Utility database (Was: RE: Autovacuum in the backend)