Re: Problems backing up

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Sebastien Boisvert <sebastienboisvert(at)yahoo(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Problems backing up
Date: 2010-04-07 17:33:19
Message-ID: 17759.1270661599@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Sebastien Boisvert <sebastienboisvert(at)yahoo(dot)com> writes:
> ----- Original Message ----
>> From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
>>> [ COPY fails to dump a 138MB bytea column ]

>> I wonder whether you are doing anything that exacerbates
>> the memory requirement, for instance by forcing an encoding conversion to
>> something other than the database's server_encoding.

> Our backups are done with the "-F c" (in addition to the normal user/host/port options). As far as I know that shouldn't be
> triggering any type conversions (which is UTF8 all-around).

No, that wouldn't do it. I'm thinking about forcing client_encoding to
be different from the database encoding, via pg_dump's -E switch, or
indirectly via PGCLIENTENCODING or PGOPTIONS or a user-specific
client_encoding setting (there are some other ways to set
client_encoding too). You could double check that by seeing what
client_encoding is specified in pg_dump's output.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Vick Khera 2010-04-07 19:27:02 Re: Solid State Drives with PG
Previous Message Pavel Stehule 2010-04-07 17:12:18 Re: count with high allocation