Re: Avoid memory leaks during base backups

From: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Cary Huang <cary(dot)huang(at)highgo(dot)ca>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Avoid memory leaks during base backups
Date: 2022-10-21 15:32:04
Message-ID: CALj2ACWDrW2mbyYd1z_yRBVTa+hr_PxyhwwK18njY7WtAzWrcQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Oct 21, 2022 at 11:58 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> To be exact, it seems to me that tablespace_map and backup_state
> should be reset before deleting backupcontext, but the reset of
> backupcontext should happen after the fact.
>
> + backup_state = NULL;
> tablespace_map = NULL;
> These two in pg_backup_start() don't matter, do they? They are
> reallocated a couple of lines down.

After all, that is what is being discussed here; what if palloc down
below fails and they're not reset to NULL after MemoryContextReset()?

> + * across. We keep the memory allocated in this memory context less,
> What does "We keep the memory allocated in this memory context less"
> mean here?

We try to keep it less because we don't want to allocate more memory
and leak it unless pg_start_backup() is called again. Please read the
description. I'll leave it to the committer's discretion whether to
have that part or remove it.

On Fri, Oct 21, 2022 at 12:11 PM Kyotaro Horiguchi
<horikyota(dot)ntt(at)gmail(dot)com> wrote:
>
>
> + * across. We keep the memory allocated in this memory context less,
> + * because any error before reaching pg_backup_stop() can leak the memory
> + * until pg_backup_start() is called again. While this is not smart, it
> + * helps to keep things simple.
>
> I think the "less" is somewhat obscure. I feel we should be more
> explicitly. And we don't need to put emphasis on "leak". I recklessly
> propose this as the draft.

I tried to put it simple, please see the attached v10. I'll leave it
to the committer's discretion for better wording.

On Fri, Oct 21, 2022 at 7:47 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Fri, Oct 21, 2022 at 2:18 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> > AFAIK, one of the callbacks associated to a memory context could
> > fail, see comments before MemoryContextCallResetCallbacks() in
> > MemoryContextDelete(). I agree that it should not matter here, but I
> > think that it is better to reset the pointers before attempting the
> > deletion of the memory context in this case.
>
> I think this is nitpicking. There's no real danger here, and if there
> were, the error handling would have to take it into account somehow,
> which it doesn't.
>
> I'd probably do it before resetting the context as a matter of style,
> to make it clear that there's no window in which the pointers are set
> but referencing invalid memory. But I do not think it makes any
> practical difference at all.

Please see the attached v10.

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

Attachment Content-Type Size
v10-0001-Avoid-memory-leaks-during-backups-using-SQL-call.patch application/x-patch 3.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Matthias van de Meent 2022-10-21 15:50:32 Re: Missing update of all_hasnulls in BRIN opclasses
Previous Message Tomas Vondra 2022-10-21 15:23:45 Missing update of all_hasnulls in BRIN opclasses