Memory usage and pg_dump

% pg_dump trans > attempt.db

generates a nice little process

PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
2881 prlw1 2 0 512K 1248K select 0:02 2.88% 2.78% pg_dump

and provides a backup. I am about to change a schema however, and

% pg_dump -D trans > attempt.db

generates a monster:

Memory: 146M Act, 73M Inact, 3792K Wired, 940K Free, 107M Swp, 181M Swp free

PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
2949 postgres 62 0 2904K 2520K RUN 2:44 50.83% 50.83% postgres
2948 prlw1 2 0 127M 77M select 1:31 46.97% 46.97% pg_dump

which then gets confused when SIZE reaches 128Mb: (odd as there is 256Mb phys
mem)

Backend sent B message without prior T

and so on, which then leads to a core dump:

#0 0x4808944e in appendPQExpBufferStr (str=0x806535c, data=0x0)
at pqexpbuffer.c:265
#1 0x480858ae in PQexec (conn=0x8065200,
query=0x8096400 "SELECT * FROM ONLY \"trans\"") at fe-exec.c:1244
#2 0x804a0cd in dumpClasses_dumpData (fout=0x8065000, oid=0x8078230 "22556",
dctxv=0x8078200) at pg_dump.c:514
#3 0x80582fa in _PrintTocData (AH=0x8065000, te=0x8085e00, ropt=0x8095f00)
at pg_backup_null.c:104
#4 0x8053851 in RestoreArchive (AHX=0x8065000, ropt=0x8095f00)
at pg_backup_archiver.c:370
#5 0x804b15b in main (argc=3, argv=0xbfbfd498) at pg_dump.c:1155
#6 0x8049bd9 in ___start ()

which is essentially strlen(0) being unhappy.. (due to the inconsistent
messages leading to zero data?)

Anyway, any idea why the behaviour is so different, and how I might tinker
with the schema? (Presumably alter table add column is the way forward, but is
that really the same as dump, edit schema, create, reload data?)

Cheers,

Patrick