Japin Li writes:
> Do those mean we cannot store 1GB to a field [1] and send 1GB of data to the
> client?
That's what I said upthread. I'm not terribly excited about that.
Shoving gigabyte-sized field values around as atomic strings is not
going to lead to anything but pain: even if the server
On Thu, 26 May 2022 at 09:03, Japin Li wrote:
> On Wed, 25 May 2022 at 22:50, Tom Lane wrote:
>> Japin Li writes:
>>> Today, I try to use repeat() to generate 1GB text, and it occurs invalid
>>> memory
>>> alloc request size [1]. It is a limit from palloc(), then I try to reduce
>>> it,
On Wed, 25 May 2022 at 22:50, Tom Lane wrote:
> Japin Li writes:
>> Today, I try to use repeat() to generate 1GB text, and it occurs invalid
>> memory
>> alloc request size [1]. It is a limit from palloc(), then I try to reduce
>> it,
>> it still complains out of memory which comes from
On Wed, 25 May 2022 at 22:41, David G. Johnston
wrote:
> On Wednesday, May 25, 2022, Japin Li wrote:
>
>>
>> Hi,
>>
>> Today, I try to use repeat() to generate 1GB text, and it occurs invalid
>> memory
>> alloc request size [1]. It is a limit from palloc(), then I try to reduce
>> it,
>> it
Japin Li writes:
> Today, I try to use repeat() to generate 1GB text, and it occurs invalid
> memory
> alloc request size [1]. It is a limit from palloc(), then I try to reduce it,
> it still complains out of memory which comes from enlargeStringInfo() [2].
> The
> documentation about
On Wednesday, May 25, 2022, Japin Li wrote:
>
> Hi,
>
> Today, I try to use repeat() to generate 1GB text, and it occurs invalid
> memory
> alloc request size [1]. It is a limit from palloc(), then I try to reduce
> it,
> it still complains out of memory which comes from enlargeStringInfo()
>
