Sloppiness around failure handling of parsePGArray in pg_dump

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Sloppiness around failure handling of parsePGArray in pg_dump
Дата
Msg-id 20201111061319.GE2276@paquier.xyz
обсуждение исходный текст
Ответы Re: Sloppiness around failure handling of parsePGArray in pg_dump
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: proposal: possibility to read dumped table's name from file
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Skip ExecCheckRTPerms in CTAS with no data