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 по дате отправления: