On 2019-Oct-03, Tom Lane wrote:
> I wrote:
> > [ v2-0001-cope-with-large-encoding-conversions.patch ]
> > [ v2-0002-actually-recover-space-in-repalloc.patch ]
>
> I've pushed these patches (after some more review and cosmetic
> adjustments) and marked the CF entry closed. Andres is welcome
> to
I wrote:
> [ v2-0001-cope-with-large-encoding-conversions.patch ]
> [ v2-0002-actually-recover-space-in-repalloc.patch ]
I've pushed these patches (after some more review and cosmetic
adjustments) and marked the CF entry closed. Andres is welcome
to see if he can improve the situation further.
Hi,
On September 24, 2019 3:09:28 PM PDT, Tom Lane wrote:
>Andres Freund writes:
>> On 2019-09-24 16:19:41 -0400, Tom Lane wrote:
>>> Andres Freund writes:
It's probably too big a hammer for this specific case, but I think
>at
some point we ought to stop using fixed size allocations
Andres Freund writes:
> On 2019-09-24 16:19:41 -0400, Tom Lane wrote:
>> Andres Freund writes:
>>> It's probably too big a hammer for this specific case, but I think at
>>> some point we ought to stop using fixed size allocations for this kind
>>> of work. Instead we should use something roughly
On 2019-09-24 16:19:41 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2019-08-16 17:31:49 -0400, Tom Lane wrote:
> >> I fear that allowing pg_do_encoding_conversion to return strings longer
> >> than 1GB is just going to create failure cases somewhere else.
> >>
> >> However, it's certainly
Andres Freund writes:
> On 2019-08-16 17:31:49 -0400, Tom Lane wrote:
>> I fear that allowing pg_do_encoding_conversion to return strings longer
>> than 1GB is just going to create failure cases somewhere else.
>>
>> However, it's certainly true that 4x growth is a pretty unlikely worst
>> case.
Hi,
On 2019-08-16 17:31:49 -0400, Tom Lane wrote:
> Alvaro Herrera writes:
> > Somebody ran into issues when generating large XML output (upwards of
> > 256 MB) and then sending via a connection with a different
> > client_encoding. This occurs because we pessimistically allocate 4x as
> > much
Alvaro Herrera writes:
> Somebody ran into issues when generating large XML output (upwards of
> 256 MB) and then sending via a connection with a different
> client_encoding. This occurs because we pessimistically allocate 4x as
> much memory as the string needs, and we run into the 1GB palloc
>
On 2019-Aug-16, Alvaro Herrera wrote:
> Somebody ran into issues when generating large XML output (upwards of
> 256 MB) and then sending via a connection with a different
> client_encoding.
ref: https://postgr.es/m/43a889a1-45fb-1d60-31ae-21e607307...@gmail.com
(pgsql-es-ayuda)
--
Álvaro Herrer
Somebody ran into issues when generating large XML output (upwards of
256 MB) and then sending via a connection with a different
client_encoding. This occurs because we pessimistically allocate 4x as
much memory as the string needs, and we run into the 1GB palloc
limitation. ISTM we can do better
10 matches
Mail list logo
