| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
| Cc: | Daniel Verite <daniel(at)manitou-mail(dot)org>, Charles Martin <ssappeals(at)gmail(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Trouble Upgrading Postgres |
| Date: | 2018-11-06 17:53:31 |
| Message-ID: | 27073.1541526811@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> writes:
> On 11/6/18 8:27 AM, Daniel Verite wrote:
>> Adrian Klaver wrote:
>>> To me that looks like a bug, putting data into a record you cannot get out.
>> Strictly speaking, it could probably get out with COPY in binary format,
>> but pg_dump doesn't use that.
Another possibility, seeing that the problematic data is bytea, is that
it might depend on whether you use hex or escape bytea_output format.
Hex format is reliably twice the size of the stored data, but escape
format could be anywhere from the same size as the stored data to four
times the size, depending on the contents. pg_dump is agnostic about this
and will just dump using the prevailing bytea_output setting, so you might
be able to get it to work by changing that setting.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ravi Krishna | 2018-11-06 17:57:31 | Re: why select count(*) consumes wal logs |
| Previous Message | Tom Lane | 2018-11-06 17:40:11 | Re: why select count(*) consumes wal logs |