Re: FATAL 1: Memory exhausted in AllocSetAlloc()

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: FATAL 1: Memory exhausted in AllocSetAlloc()
Дата
Msg-id 11829.979233495@sss.pgh.pa.us
обсуждение исходный текст
Ответ на FATAL 1: Memory exhausted in AllocSetAlloc()  ("Thomas Heller" <th.heller@comtron.net>)
Список pgsql-admin
"Thomas Heller" <th.heller@comtron.net> writes:
> [ after a system crash, I'm getting ]
> FATAL 1:  Memory exhausted in AllocSetAlloc()

An educated guess is that you have a corrupted tuple in some table,
within which a variable-length datum is corrupted in some way that
makes it appear to have a size of hundreds of megabytes (more than
your allowed process swap space, anyway).  VACUUM ANALYZE, or anything
else that tries to examine the corrupted datum, will start out by
trying to palloc() as much space as the datum's length word says it
needs.  Malloc failure leads to the above complaint and emergency
stop.  No (further) harm done to your table, fortunately.

What you want to do is narrow down the location of the bad tuple (or
tuples; there might be more than one) and then delete it.  It should
be easy enough to determine which table(s) contain bad data --- one
way is to VACUUM ANALYZE tables one at a time to see which ones fail.
To locate the bad tuple, one way is to do

    SELECT * FROM foo LIMIT n;

for various n and see which queries succeed and which don't.  With
a little bit of homing in, you can determine that the n'th tuple of
the table is broken.  Then you can do something like

    SELECT oid FROM foo OFFSET n-1 LIMIT 1;

    DELETE FROM foo WHERE oid = value-just-determined;

to zap the tuple without trying to examine its corrupted column.

Repeat if necessary until all tables are clean ...

            regards, tom lane

В списке pgsql-admin по дате отправления:

Предыдущее
От: "Thomas Heller"
Дата:
Сообщение: FATAL 1: Memory exhausted in AllocSetAlloc()
Следующее
От: Karla Peralta
Дата:
Сообщение: Encrypt