> On 19 Nov 2020, at 02:37, Michael Paquier wrote:
>
> On Wed, Nov 18, 2020 at 10:19:40AM +0100, Daniel Gustafsson wrote:
>> I agree that we should fix this even if it will have quite limited impact in
>> production settings. Patch LGTM, +1.
>
> Thanks. I have reviewed that again this morning
On Wed, Nov 18, 2020 at 10:19:40AM +0100, Daniel Gustafsson wrote:
> I agree that we should fix this even if it will have quite limited impact in
> production settings. Patch LGTM, +1.
Thanks. I have reviewed that again this morning and applied it.
> Another thing caught my eye here (while not
> On 11 Nov 2020, at 07:13, Michael Paquier wrote:
> I would like to propose the attached to tighten the error handling in
> the area, generating a fatal error if an array cannot be parsed.
I agree that we should fix this even if it will have quite limited impact in
production settings. Patch L
Hi all,
Following the report of Coverity that led to 3636efa, I have reviewed
the existing callers of parsePGArray() in pg_dump and some of its
error handling is a bit sloppy.
It could theoretically be possible to reach an OOM in parsePGArray()
with a dump able to finish. This is very unlikely g