Re: pg_dump - lost synchronization with server: got message type "d", length 6036499

From: Klint Gore <kgore4(at)une(dot)edu(dot)au>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-general General <pgsql-general(at)postgresql(dot)org>
Subject: Re: pg_dump - lost synchronization with server: got message type "d", length 6036499
Date: 2008-07-03 01:20:12
Message-ID: 486C294C.4000400@une.edu.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Tom Lane wrote:
> Klint Gore <kgore4(at)une(dot)edu(dot)au> writes:
> > Tom Lane wrote:
> >> Maybe it's
> >> dying here after having leaked a lot of memory for some other reason
> >> --- try watching the pg_dump process size while it runs.
>
> > Peak memory usage was about 540m which brought the total usage for the
> > machine to about half the physical memory allocated (3g total).
>
> Well, that might well explain the failure. pg_dump does suck a lot of
> schema information into memory at startup, but 540m seems excessive.
> Maybe you've found a memory leak in pg_dump (it wouldn't be the first
> one). Does this database have a particularly large number of objects?
>
> regards, tom lane
>
>
I wouldn't call it large - 27 tables, 111 functions, 21 custom types
(used for set returning function results).

The biggest row count table has about 200k records (structure is
int,int,timestamp)

The biggest physical table is the one thats failiing. The table itself
is physically 81m and its toast table is 82m.

klint.

--
Klint Gore
Database Manager
Sheep CRC
A.G.B.U.
University of New England
Armidale NSW 2350

Ph: 02 6773 3789
Fax: 02 6773 3266
EMail: kgore4(at)une(dot)edu(dot)au

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Gurjeet Singh 2008-07-03 01:55:03 Confusion about ident sameuser
Previous Message Matt Magoffin 2008-07-03 01:19:27 Re: Memory use in 8.3 plpgsql with heavy use of xpath()