Re: pg_upgrade: out of memory - Mailing list pgsql-general
From | Andrew Hastie |
---|---|
Subject | Re: pg_upgrade: out of memory |
Date | |
Msg-id | 5069D778.7070601@ahastie.net Whole thread Raw |
In response to | Re: pg_upgrade: out of memory ("Carrington, Matthew (Produban)" <Matthew.Carrington@Produban.co.uk>) |
Responses |
Re: pg_upgrade: out of memory
|
List | pgsql-general |
Tom/Matthew, I also tried the same macro with the xlc compiler with similar results in that pg_dump now works as expected :-) For info here's my build setup:- ./configure CC=xlc LIBS="-lssl -lcrypto -lz -lreadline -lcurses -lld -lmass -lm" CFLAGS="-qlanglvl=extc89 -D_LINUX_SOURCE_COMPAT" --with-template=aix --prefix=/home/ahastie/pgbuild --with-includes=/opt/freeware/include --with-libraries=/opt/freeware/lib gmake gmake check gmake install Tom: Is this something we should get added into the AIX Platform specific notes? Regards, Andrew On 01/10/12 15:50, Carrington, Matthew (Produban) wrote: > Tom, > > Following on from that man page extract I tried a build using the suggested compiler macro (_LINUX_SOURCE_COMPAT) ... > > export "CC=/opt/freeware/bin/gcc -maix64" > export OBJECT_MODE=64 > export CFLAGS="-D_LINUX_SOURCE_COMPAT -maix64 -g" > export LDFLAGS="-maix64 -Wl,-bbigtoc" > export AR="ar -X64" > export "CC=/opt/freeware/bin/gcc -maix64" > > ./configure --enable-debug --prefix=/opt/serviceMonitoring/postgres_9.2.1 --disable-thread-safety --enable-cassert > > make > cd contrib > make > cd .. > make install > cd contrib > make install > > ... and tried it out ... > > "/opt/serviceMonitoring/postgres_9.2.1/bin/pg_dump" --port 65432 --username "postgres" --verbose --schema-only --binary-upgrade-f dump.out template1 > > .. and the full dump as per pg_upgrade ... > > "/opt/serviceMonitoring/postgres_9.2.1/bin/pg_dumpall" --port 65432 --username "postgres" --schema-only --binary-upgrade-f pg_upgrade_dump_all.sql > > .. both of which worked without any problems. > > Hope that helps. > > Matthew > > -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > Sent: 01 October 2012 14:39 > To: Carrington, Matthew (Produban) > Cc: pgsql-general@postgresql.org > Subject: Re: [GENERAL] pg_upgrade: out of memory > > "Carrington, Matthew (Produban)" <Matthew.Carrington@produban.co.uk> writes: >> pg_dump: reading user-defined aggregate functions >> Breakpoint 1, exit_horribly (modulename=0x0, fmt=0x10006a590 "out of memory\n") >> at dumputils.c:1314 >> 1314 dumputils.c: A file or directory in the path name does not exist.. >> (gdb) bt >> #0 exit_horribly (modulename=0x0, fmt=0x10006a590 "out of memory\n") at dumputils.c:1314 >> #1 0x000000010003247c in pg_malloc (size=0) at dumpmem.c:47 >> #2 0x0000000100008f54 in getAggregates (fout=0x11000bad0, numAggs=0xffffffffffff73c) >> at pg_dump.c:3614 > Oh! Given your previous comment about there not being any user-defined > aggregates, I see what the problem is. AIX must be one of the platforms > where malloc(0) is defined to return NULL rather than a pointer to a > zero-size block. pg_malloc is not coping with that. > > A quick fix would be > > pg_malloc(size_t size) > { > void *tmp; > > tmp = malloc(size); > - if (!tmp) > + if (!tmp && size) > { > psql_error("out of memory\n"); > exit(EXIT_FAILURE); > } > > but I'm not sure if that's the best answer overall. Will take it up in > -hackers. > > regards, tom lane > Emails aren't always secure, and they may be intercepted or changed > after they've been sent. Produban doesn't accept liability if this > happens. If you think someone may have interfered with this email, > please get in touch with the sender another way. This message and any > documents attached to it do not create or change any contract unless > otherwise specifically stated. Any views or opinions contained in this > message are solely those of the author, and do not necessarily represent > those of Produban, unless otherwise specifically stated and the sender > is authorised to do so. Produban doesn't accept responsibility for > damage caused by any viruses contained in this email or its attachments. > Emails may be monitored. If you've received this email by mistake, > please let the sender know at once that it's gone to the wrong person > and then destroy it without copying, using, or telling anyone about its > contents. Produban Servicios Informaticos Generales, S.L. (UK Branch). > Registered office: Shenley Wood House, Chalkdell Drive, Shenley Wood, > Milton Keynes MK5 6LA. Branch registration number BR 008486. > Ref:[PDB#014] > > >
pgsql-general by date: