Re: [GENERAL] FATAL 1: Memory exhausted in AllocSetAlloc()
От | Martin Weinberg |
---|---|
Тема | Re: [GENERAL] FATAL 1: Memory exhausted in AllocSetAlloc() |
Дата | |
Msg-id | 199909262054.QAA18092@osprey.astro.umass.edu обсуждение исходный текст |
Ответ на | FATAL 1: Memory exhausted in AllocSetAlloc() ("Tim Joyce" <tim@hoop.co.uk>) |
Список | pgsql-general |
Tim, I've been trying to get around the same problem for the last week but haven't been able to trace it down. Here's what I found so far: 1) I have had the "Memory exhausted" in both vacuum and copy. It is not obviously reproducible; that is, if I repeat the same command it may not fail, or fail in a different place 2) The AllocSet...() routines are in src//backend/utils/mmgr/aset.c. They are wrappers around malloc. 3) My machine has 256Mb and the postgres user has unlimited memory limit. The backend does not appear to be growing at all when the condition occurs. 4) This seems to rear it's head for large databases only. The tables I am trying to vacuum and copy have about 50 million records each. Small databases seem to be fine. All of this leads me to suspect a memory bug somewhere. I have set PGBUFFERS to 3500 to maximize use of available shmem. The backend does not seem to grow beyond the resulting ~30Mb. I do not know if this is related. I am running 6.5.1 (and have tried 6.5.2) with Linux 2.2.10 under the Debian 2.1 (slink) distribution. I compiled Oliver Elphick's 6.5.1 source package against slink which up to floating point issues, passes the regression tests successfully. Perhaps Oliver can tell us if this might have introduced a problem? Maybe a pgsql hacker/guru has a clue? I'm not sufficiently well- versed with the guts to know what else to do. --Martin =========================================================================== Martin Weinberg Phone: (413) 545-3821 Dept. of Physics and Astronomy FAX: (413) 545-2117/0648 530 Graduate Research Tower weinberg@astro.umass.edu University of Massachusetts http://www.astro.umass.edu/~weinberg/ Amherst, MA 01003-4525
В списке pgsql-general по дате отправления: