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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
