Re: pg_dumpall 8.1.4 large objects error - Mailing list pgsql-admin

From Jeff Frost
Subject Re: pg_dumpall 8.1.4 large objects error
Date
Msg-id Pine.LNX.4.64.0606090918550.27250@glacier.frostconsultingllc.com
Whole thread Raw
In response to Re: pg_dumpall 8.1.4 large objects error  (Jeff Frost <jeff@frostconsultingllc.com>)
Responses Re: pg_dumpall 8.1.4 large objects error  (Jeff Frost <jeff@frostconsultingllc.com>)
Re: pg_dumpall 8.1.4 large objects error  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-admin
On Wed, 7 Jun 2006, Jeff Frost wrote:

> On Tue, 6 Jun 2006, Tom Lane wrote:
>
>> Some cursory trawling in the REL7_3 sources says that this means that
>> "SELECT DISTINCT loid FROM pg_largeobject" found a large object OID
>> that then could not be found by an indexscan of pg_largeobject.  So
>> I'd try a REINDEX of pg_largeobject to see if that fixes it.  See the
>> REINDEX man page concerning hoops you have to jump through to reindex
>> a system catalog --- IIRC, the hoops are much higher and narrower back
>> in 7.3.
>

Got the REINDEX completed and found a new error that I haven't seen before:

pg_dump: SQL command failed
pg_dump: Error message from server: ERROR:  Memory exhausted in AllocSetAlloc(96)
pg_dump: The command was: FETCH 100 IN blobcmt
pg_dumpall: pg_dump failed on database "vsl_cs", exiting

I was dumping like so:

/usr/local/pgsql-8.1.4/bin/pg_dumpall | /usr/bin/bzip2 > vsl_cs-20060608.sql.bz2

Would it be better and more efficient to just pg_dumpall the globals and
pg_dump in custom format the vsl_cs db?  There's actually only one DB on the
systems besides the system dbs.  Server is 7.3.2, and the plan is to upgrade
it.

--
Jeff Frost, Owner     <jeff@frostconsultingllc.com>
Frost Consulting, LLC     http://www.frostconsultingllc.com/
Phone: 650-780-7908    FAX: 650-649-1954

pgsql-admin by date:

Previous
From: "Chris Hoover"
Date:
Subject: Best way to index large text/varchar fields
Next
From: "Joshua D. Drake"
Date:
Subject: Re: Best way to index large text/varchar fields