Re: MemoryContextAlloc: invalid request size

Поиск
Список
Период
Сортировка
От Brusser, Michael
Тема Re: MemoryContextAlloc: invalid request size
Дата
Msg-id 9150DCE0CCB4D411A7DB00508BB0DBF21031E4C8@msx1am.matrixone.net
обсуждение исходный текст
Ответ на MemoryContextAlloc: invalid request size  ("Brusser, Michael" <Michael.Brusser@matrixone.com>)
Список 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 по дате отправления:

Предыдущее
От: "Dave Page"
Дата:
Сообщение: Re: Utility database (Was: RE: Autovacuum in the backend)
Следующее
От: "Dave Page"
Дата:
Сообщение: Re: Utility database