Re: pg_upgrade: out of memory

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(at)sss(dot)pgh(dot)pa(dot)us]
> Sent: 01 October 2012 14:39
> To: Carrington, Matthew (Produban)
> Cc: pgsql-general(at)postgresql(dot)org
> Subject: Re: [GENERAL] pg_upgrade: out of memory
>
> "Carrington, Matthew (Produban)" <Matthew(dot)Carrington(at)produban(dot)co(dot)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]
>
>
>