From: Tom Lane <tgl@sss.pgh.pa.us>
To: "Daniel Verite" <daniel@manitou-mail.org>
cc: "Alvaro Herrera" <alvherre@2ndquadrant.com>,
        "Robert Haas" <robertmhaas@gmail.com>,
        "Jim Nasby" <Jim.Nasby@bluetreble.com>,
        "Ronan Dunklau" <ronan.dunklau@dalibo.com>,
        "pgsql-hackers" <pgsql-hackers@postgresql.org>
Subject: Re: pg_dump / copy bugs with "big lines" ?
In-reply-to: <149c79ee-9f41-48e1-83f8-3b2fe90af2b6@mm>
References: <149c79ee-9f41-48e1-83f8-3b2fe90af2b6@mm>
Comments: In-reply-to "Daniel Verite" <daniel@manitou-mail.org>
	message dated "Tue, 01 Mar 2016 22:31:19 +0100"
Date: Tue, 01 Mar 2016 16:48:43 -0500
Message-ID: <27428.1456868923@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

"Daniel Verite" <daniel@manitou-mail.org> writes:
> I've tried adding another large field to see what happens if the whole row
> exceeds 2GB, and data goes to the client rather than to a file.
> My idea was to check if the client side was OK with that much data on
> a single COPY row, but it turns out that the server is not OK anyway.

BTW, is anyone checking the other side of this, ie "COPY IN" with equally
wide rows?  There doesn't seem to be a lot of value in supporting dump
if you can't reload ...

			regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers