Seneca Cunningham wrote:
You're using a 32-bit build with the default memory model, it would
seem. You're limited to less than 256MB for the heap in that model.
Try stopping the postmaster and starting it back up with the
environment variable LDR_CNTRL set to "MAXDATA=0x80000000". This
expands the heap to 2GB and if it helps, you can use ldedit on your
postgres binaries to make that the default (or rebuild, passing the
linker "-bmaxdata:0x80000000").
Yep you're right on the money with default everything, and the kernel is
indeed 32-bit. Still a bit of a mixed bag tho :)
Last night, I passed
$ LDR_CNTRL="MAXDATA=0x8000000" bin/pg_ctl start -D /usr/local/pgsql/share/
Which immediately threw back an 'shm' error that the process table was
full, so I tried with a more modest 0x4000000 request and that worked a
treat; autovac ran fine and a full pg_restore completed perfectly -
hurrah! :)
This morning, however, pg starts with either 0x8000000 or 0x4000000,
but I am right back at square one with the same messages when autovac fires:
"2006-03-29 09:18:45 BSTERROR: out of memory
2006-03-29 09:18:45 BSTDETAIL: Failed on request of size 268435452." so
I'm at a loss :)
Would it be better to 'Enable 64-bit application environment' as the
option in 'smitty' has kept tempting me with? Or use the AIX 64-bit
kernel instead? Or both? :)) I'm using gcc 4.1.0 to compile pg - would I
need to recompile with any particular flags for 64-bit goodness?
Anyway, "Large Program Support"[1] from the AIX docs give an overview
of the situation. Chapter 3 of the redbook "Developing and porting C
and C++ Applications on AIX"[2] goes into all the gory details of
what's happening.
[1]
http://publib.boulder.ibm.com/infocenter/pseries/topic/com.ibm.aix.doc/aixprggd/genprogc/lrg_prg_support.htm
Wow, that's quite some bedtime reading - hopefully some day I will be
able to read it without feeling that my brain is about to melt :)
FAO Tom Lane - I have maintenance_work_mem set to 256MB, so that also
matches perfectly with the size of the out of memory error :)
Cheers,
Gavin.
