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
