At Wed, 28 Sep 2022 13:16:36 +0900, Michael Paquier <mich...@paquier.xyz> wrote in > 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.rupireddyforpostg...@gmail.com> wrote in > > > On Mon, Sep 26, 2022 at 7:34 PM Tom Lane <t...@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..
If I understand you correctly, my point was the usage of error callbacks. I meant that we can release that tangling memory blocks in SendBaseBackup() even by directly pfree()ing then NULLing the pointer, if the pointer were file-scoped static. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
