| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Daniel Verite" <daniel(at)manitou-mail(dot)org> |
| Cc: | "Alvaro Herrera" <alvherre(at)2ndquadrant(dot)com>, "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Jim Nasby" <Jim(dot)Nasby(at)bluetreble(dot)com>, "Ronan Dunklau" <ronan(dot)dunklau(at)dalibo(dot)com>, "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: pg_dump / copy bugs with "big lines" ? |
| Date: | 2016-03-01 16:50:36 |
| Message-ID: | 14620.1456851036@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Daniel Verite" <daniel(at)manitou-mail(dot)org> writes:
> Alvaro Herrera wrote:
>> If others can try this patch to ensure it enables pg_dump to work on
>> their databases, it would be great.
> It doesn't seem to help if one field exceeds 1Gb, for instance when
> inflated by a bin->hex translation.
It's not going to be possible to fix that without enormously invasive
changes (affecting individual datatype I/O functions, for example).
And in general, fields approaching that size are going to give you
problems in all kinds of ways, not only COPY.
I think we should be satisfied if we can make COPY deal with the sum
of a line's fields exceeding 1GB.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Anastasia Lubennikova | 2016-03-01 16:55:12 | Re: WIP: Covering + unique indexes. |
| Previous Message | Daniel Verite | 2016-03-01 16:43:00 | Re: pg_dump / copy bugs with "big lines" ? |