Re: Sloppiness around failure handling of parsePGArray in pg_dump

2020-11-19 Thread Daniel Gustafsson
> 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

Re: Sloppiness around failure handling of parsePGArray in pg_dump

2020-11-18 Thread Michael Paquier
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

Re: Sloppiness around failure handling of parsePGArray in pg_dump

2020-11-18 Thread Daniel Gustafsson
> 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

Sloppiness around failure handling of parsePGArray in pg_dump

2020-11-10 Thread Michael Paquier
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