Re: refactoring basebackup.c

Поиск
Список
Период
Сортировка
От Jeevan Ladhe
Тема Re: refactoring basebackup.c
Дата
Msg-id CAOgcT0OeWuX+O=-5OTL8VWdjCaCh0HKDoKHDRq1zUfUrdXCnsw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: refactoring basebackup.c  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: refactoring basebackup.c  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers

I have implemented the cleanup callback bbsink_lz4_cleanup() in the attached patch.


Please have a look and let me know of any comments.


Regards,

Jeevan Ladhe


On Fri, Oct 29, 2021 at 6:54 PM Robert Haas <robertmhaas@gmail.com> wrote:
On Fri, Oct 29, 2021 at 8:59 AM Jeevan Ladhe
<jeevan.ladhe@enterprisedb.com> wrote:>
> bbsink_gzip_ops have the cleanup() callback set to NULL, and when the
> bbsink_cleanup() callback is triggered, it tries to invoke a function that
> is NULL. I think either bbsink_gzip_ops should set the cleanup callback
> to bbsink_forward_cleanup or we should be calling the cleanup() callback
> from PG_CATCH instead of PG_FINALLY()? But in the latter case, even if
> we call from PG_CATCH, it will have a similar problem for gzip and other
> sinks which may not need a custom cleanup() callback in case there is any
> error before the backup could finish up normally.
>
> I have attached a patch to fix this.

Yes, this is the right fix. Apologies for the oversight.

--
Robert Haas
EDB: http://www.enterprisedb.com
Вложения

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

Предыдущее
От: Ajin Cherian
Дата:
Сообщение: Re: row filtering for logical replication
Следующее
От: Hayk Manukyan
Дата:
Сообщение: Re: Feature request for adoptive indexes