Sloppiness around failure handling of parsePGArray in pg_dump
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-11-11T06:13:19Z
Lists: pgsql-hackers
Attachments
- dump-array-error.patch (text/x-diff) patch
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 going to matter in practice as an OOM when parsing an array is most likely going to trigger a fatal failure in one of the follow-up allocations, but if the dump is able to go through we could finish with a valid dump that lacks some information: - Statistics for indexes. - Run-time configuration of functions. - Configuration of extensions. - Publication list for a subscription. 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 did not see the point of changing the assumptions we use for the parsing of function args or such when it comes to pre-8.4 dumps. This issue is unlikely going to matter in practice, so I don't propose a backpatch. Thoughts? -- Michael
Commits
-
Improve failure detection with array parsing in pg_dump
- 13b58f8934e6 14.0 landed