From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Japin Li <japinli(at)hotmail(dot)com> |
Cc: | "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Invalid memory alloc request size for repeat() |
Date: | 2022-05-25 14:50:52 |
Message-ID: | 1926262.1653490252@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Japin Li <japinli(at)hotmail(dot)com> 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 repect() [3] doesn't mentaion the limitation.
It would probably make sense for repeat() to check this explicitly:
if (unlikely(pg_mul_s32_overflow(count, slen, &tlen)) ||
- unlikely(pg_add_s32_overflow(tlen, VARHDRSZ, &tlen)))
+ unlikely(pg_add_s32_overflow(tlen, VARHDRSZ, &tlen)) ||
+ unlikely(!AllocSizeIsValid(tlen)))
ereport(ERROR,
(errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
errmsg("requested length too large")));
The failure in enlargeStringInfo is probably coming from trying to
construct an output message to send back to the client. That's
going to be a lot harder to do anything nice about (and even if
the backend didn't fail, the client might).
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Matthias van de Meent | 2022-05-25 15:20:30 | Re: adding status for COPY progress report |
Previous Message | David G. Johnston | 2022-05-25 14:41:11 | Re: Invalid memory alloc request size for repeat() |