Re: Plug minor memleak in pg_dump

Поиск
Список
Период
Сортировка
От Daniel Gustafsson
Тема Re: Plug minor memleak in pg_dump
Дата
Msg-id 70019E5D-A6AB-43BA-84F9-D36EB8C678B6@yesql.se
обсуждение исходный текст
Ответ на Re: Plug minor memleak in pg_dump  (Ranier Vilela <ranier.vf@gmail.com>)
Ответы Re: Plug minor memleak in pg_dump  (Ranier Vilela <ranier.vf@gmail.com>)
Список pgsql-hackers
> On 10 Feb 2022, at 12:14, Ranier Vilela <ranier.vf@gmail.com> wrote:
> Em qua., 9 de fev. de 2022 às 23:16, Michael Paquier <michael@paquier.xyz <mailto:michael@paquier.xyz>> escreveu:

> This patch makes things worse, doesn't it?
> No.
>
> Doesn't this localized
> change mean that we expose ourselves more into *ignoring* TOC entries
> if we mess up with this code in the future?
> InvalidOid already used for "default".

There is no default case here, setting the tableoid to InvalidOid is done when
the archive doesn't support this particular feature.  If we can't read the
tableoid here, it's a corrupt TOC and we should abort.

> If ReadStr fails and returns NULL, sscanf will crash.

Yes, which is better than silently propage the error.

> Maybe in this case, better report to the user?
> pg_log_warning?

That would demote what is today a crash to a warning on a corrupt TOC entry,
which I think is the wrong way to go.  Question is, can this fail in a
non-synthetic case on output which was successfully generated by pg_dump?  I'm
not saying we should ignore errors, but I have a feeling that any input fed
that triggers this will be broken enough to cause fireworks elsewhere too, and
this being a chase towards low returns apart from complicating the code.

--
Daniel Gustafsson        https://vmware.com/




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

Предыдущее
От: Ranier Vilela
Дата:
Сообщение: Re: Plug minor memleak in pg_dump
Следующее
От: Jeevan Ladhe
Дата:
Сообщение: Re: refactoring basebackup.c