Daniel Verite wrote:
> If we consider what would happen with the latest patch on a platform
> with sizeof(int)=8 and a \copy invocation like this:
>
> \copy (select big,big,big,big,big,big,big,big,...... FROM
> (select lpad('', 1024*1024*200) as big) s) TO /dev/null
>
> if we put enough copies of "big" in the select-list to grow over 2GB,
> and then over 4GB.
Oh, right, I was forgetting that.
> On a platform with sizeof(int)=4 this should normally fail over 2GB with
> "Cannot enlarge string buffer containing $X bytes by $Y more bytes"
>
> I don't have an ILP64 environment myself to test, but I suspect
> it would malfunction instead of cleanly erroring out on such
> platforms.
I suspect nobody has such platforms, as they are mostly defunct. But I
see an easy way to fix it, which is to use sizeof(int32).
> Also, without this limit, we can "COPY FROM/TO file" really huge rows, 4GB
> and beyond, like I tried successfully during the tests mentioned upthread
> (again with len as int64 on x86_64).
> So such COPYs would succeed or fail depending on whether they deal with
> a file or a network connection.
> Do we want this difference in behavior?
Such a patch would be for master only.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
