Re: Bound memory usage during manual slot sync retries

From: Xuneng Zhou <xunengzhou(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "itsajin(at)gmail(dot)com" <itsajin(at)gmail(dot)com>, "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com>
Subject: Re: Bound memory usage during manual slot sync retries
Date: 2026-05-26 20:01:09
Message-ID: CABPTF7XCcMq=AeCY-E67VRwo=ap53bfmKngr289PirAo4XuUXA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Mon, May 25, 2026 at 7:03 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
> wrote:
> >
> > Okay, then let's go with a per-retry memory context approach.
> >
> > @@ -579,6 +579,8 @@ drop_local_obsolete_slots(List *remote_slot_list)
> > local_slot->data.database));
> > }
> > }
> > +
> > + list_free(local_slots);
> > }
> >
> > Why do we need this retail pfree if the caller is using memory context?
> >
>
> I see that the latest patch in email [1] has already addressed this
> point. So, I'll push the v2 version.
>
> [1] -
> https://www.postgresql.org/message-id/CABPTF7WB4Z62sPoZkhSygOCAo3OiTDLpMELxZDuwCb3HYgM_pQ%40mail.gmail.com

Thanks. My original reasoning for adding the pfree here was to act as a
safety guard in case other future callers might not manage the memory
properly. But Zhijie pointed out that this double-free pattern is not
favored in previous community discussions. I'll post the worst-case test
and its results later.

Regards,
Xuneng Zhou
HighGo Software Co., Ltd.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bertrand Drouvot 2026-05-26 20:18:50 Re: Avoid orphaned objects dependencies, take 3
Previous Message Nathan Bossart 2026-05-26 19:55:09 Re: future of PQfn()