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.