On Tue, Sep 27, 2022 at 05:32:26PM +0900, Kyotaro Horiguchi wrote:
> At Tue, 27 Sep 2022 11:33:56 +0530, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> wrote in
> > On Mon, Sep 26, 2022 at 7:34 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > > This ... seems like inventing your own shape of wheel. The
> > > normal mechanism for preventing this type of leak is to put the
> > > allocations in a memory context that can be reset or deallocated
> > > in mainline code at the end of the operation.
> >
> > Yes, that's the typical way and the patch attached does it for
> > perform_base_backup(). What happens if we allocate some memory in the
> > new memory context and error-out before reaching the end of operation?
> > How do we deallocate such memory?
>
> Whoever directly or indirectly catches the exception can do that. For
> example, SendBaseBackup() seems to catch execptions from
> perform_base_backup(). bbsinc_cleanup() is already resides there.
Even with that, what's the benefit in using an extra memory context in
basebackup.c? backup_label and tablespace_map are mentioned upthread,
but we have a tight control of these, and they should be allocated in
the memory context created for replication commands (grep for
"Replication command context") anyway. Using a dedicated memory
context for the SQL backup functions under TopMemoryContext could be
interesting, on the other hand..
--
Michael
