Re: pg_dump / copy bugs with "big lines" ?

Alvaro Herrera wrote:

> I propose to rename allow_long to huge_ok. "Huge" is the terminology
> used by palloc anyway. I'd keep makeLongStringInfo() and
> initLongStringInfo() though as interface, because using Huge instead of
> Long there looks strange. Not wedded to that, though (particularly as
> it's a bit inconsistent).

"Long" makes sense to me as qualifying a limit greater than
MaxAllocSize but lower (or equal) than MaxAllocHugeSize.

In memutils.h we have these definitions:

#define MaxAllocSize ((Size) 0x3fffffff) /* 1 gigabyte - 1 */
#define MaxAllocHugeSize ((Size) -1 >> 1) /* SIZE_MAX / 2 */

And in enlargeStringInfo() the patch adds this:
/*
* Maximum size for strings with allow_long=true.
* It must not exceed INT_MAX, as the StringInfo routines
* expect offsets into the buffer to fit into an int.
*/
const int max_alloc_long = 0x7fffffff;

On a 32-bit arch, we can expect max_alloc_long == MaxAllocHugeSize,
but on a 64-bit arch, it will be much smaller with MaxAllocHugeSize
at (2^63)-1.

IOW, the patch only doubles the maximum size of StringInfo
whereas we could say that it should multiply it by 2^32 to pretend to
the "huge" qualifier.

Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite