From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Sloppiness around failure handling of parsePGArray in pg_dump |
Date: | 2020-11-11 06:13:19 |
Message-ID: | 20201111061319.GE2276@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
Attachment | Content-Type | Size |
---|---|---|
dump-array-error.patch | text/x-diff | 3.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2020-11-11 06:35:25 | Re: Skip ExecCheckRTPerms in CTAS with no data |
Previous Message | Pavel Stehule | 2020-11-11 05:54:22 | Re: proposal: possibility to read dumped table's name from file |