Re: refactoring basebackup.c

From: Jeevan Ladhe <jeevan(dot)ladhe(at)enterprisedb(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, tushar <tushar(dot)ahuja(at)enterprisedb(dot)com>
Subject: Re: refactoring basebackup.c
Date: 2021-11-02 11:52:29
Message-ID: CAOgcT0OeWuX+O=-5OTL8VWdjCaCh0HKDoKHDRq1zUfUrdXCnsw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)gmail(dot)com> wrote:

> On Fri, Oct 29, 2021 at 8:59 AM Jeevan Ladhe
> <jeevan(dot)ladhe(at)enterprisedb(dot)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
>

Attachment Content-Type Size
lz4_compress_v7.patch application/octet-stream 11.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hayk Manukyan 2021-11-02 12:04:29 Re: Feature request for adoptive indexes
Previous Message Ajin Cherian 2021-11-02 11:44:05 Re: row filtering for logical replication