Re: pg_upgrade: out of memory

From: "Carrington, Matthew (Produban)" <Matthew(dot)Carrington(at)Produban(dot)co(dot)uk>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: pg_upgrade: out of memory
Date: 2012-09-21 08:46:46
Message-ID: 53E23B63FBFF3645A2CDD9BE5933C60C8B1169A81D@ENTAAP2407P.an.ad.anplc.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Tom,

As its AIX I don't have top but using topas and comparing it to other processes running a successful pg_dumpall doesn't get very large at all.

The database only has around 1000 tables and no more than anpther 500 view, triggers, functions, etc. so its not a big database. There are no BLOBs or anything even slightly non-mainstream.

The output file created by a successful pg_dumpall is 11MB for all the databases running on this postgres installation. The other databases are much larger than the first one which is where the failure occurred.

The machine is a large AIX box with 64GB of memory and the upgrade was run with nothing else running on the machine so I find it hard to believe that it is genuinely out of memory. The whole of the first database could fit in real memory as its only 28GB.

Matthew

-----Original Message-----
From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
Sent: 20 September 2012 15:48
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:
> I have attempted to upgrade my Postgres installation this morning from 9.0.1 to 9.2.0 and it failed with an out of memory problem using pg_dumpall to dump the first database.

Hm. I'm not aware of any reason for 9.2 pg_dump to take hugely more
memory than 9.0. How big is the database (how many objects)? When
you run 9.0 pg_dump against it, how big does the process get? (Watching
it in "top" is probably a close enough answer here.)

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]

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Benedikt Grundmann 2012-09-21 09:18:48 Re: Expression to construct a anonymous record with named columns?
Previous Message Alban Hertroys 2012-09-21 07:01:45 Re: Using psql -f to load a UTF8 file