Re: MemoryContextAlloc: invalid request size - Mailing list pgsql-hackers

From Brusser, Michael
Subject Re: MemoryContextAlloc: invalid request size
Date
Msg-id 9150DCE0CCB4D411A7DB00508BB0DBF21031E4C8@msx1am.matrixone.net
Whole thread Raw
In response to MemoryContextAlloc: invalid request size  ("Brusser, Michael" <Michael.Brusser@matrixone.com>)
List 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.Brusser@matrixone.com]
Sent: Thursday, June 16, 2005 8:28 PM
To: 'Pgsql-Hackers (pgsql-hackers@postgresql.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.

pgsql-hackers by date:

Previous
From: "Dave Page"
Date:
Subject: Re: Utility database (Was: RE: Autovacuum in the backend)
Next
From: "Dave Page"
Date:
Subject: Re: Utility database