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  (Tom Lane <tgl@sss.pgh.pa.us>)
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:

Previous
From: Andreas Pfotenhauer
Date:
Subject: Re: strange hot_standby behaviour
Next
From: "Yelai, Ramkumar IN BLR STS"
Date:
Subject: Re: Re: Need help in reclaiming disk space by deleting the selected records