Re: Avoid memory leaks during base backups

From: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Avoid memory leaks during base backups
Date: 2022-09-28 04:39:25
Message-ID: CALj2ACVWXD60d-mAFj60NK-NWVEzyHwBOrtEx8_a-fv0rWPtyg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Sep 28, 2022 at 9:46 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> 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(dot)rupireddyforpostgres(at)gmail(dot)com> wrote in
> > > On Mon, Sep 26, 2022 at 7:34 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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..

I had the same opinion. Here's what I think - for backup functions, we
can have the new memory context child of TopMemoryContext and for
perform_base_backup(), we can have the memory context child of
CurrentMemoryContext. With PG_TRY()-PG_FINALLY()-PG_END_TRY(), we can
delete those memory contexts upon ERRORs. This approach works for us
since backup-related code doesn't have any FATALs.

Thoughts?

--
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2022-09-28 04:40:08 Re: Extend win32 error codes to errno mapping in win32error.c
Previous Message Michael Paquier 2022-09-28 04:16:36 Re: Avoid memory leaks during base backups