Re: memory leak in logical WAL sender with pgoutput's cachectx

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>
Cc: "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com>, Xuneng Zhou <xunengzhou(at)gmail(dot)com>, 赵宇鹏(宇彭) <zhaoyupeng(dot)zyp(at)alibaba-inc(dot)com>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: memory leak in logical WAL sender with pgoutput's cachectx
Date: 2025-08-15 18:22:06
Message-ID: CAD21AoAfc-8iPiT3KCc1Jx7CygCBV6Wuay-Xt_A8y=BAD0obsg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Aug 15, 2025 at 5:07 AM Hayato Kuroda (Fujitsu)
<kuroda(dot)hayato(at)fujitsu(dot)com> wrote:
>
> Dear Sawada-san,
>
> > Given that cache invalidation is executed upon replaying
> > REORDER_BUFFER_CHANGE_INVALIDATION and the end of a transaction
> > replay, in which case do we keep the relcache (i.e. just setting
> > replicate_valid=false) because of in_use=true?
>
> Per old discussion [1], logicalrep_write_tuple ->SearchSysCache1 can cause the
> cache invalidation (I did not verify though).
> I felt in this case in_use can be true and validation can be skipped. Thought?

I've not verified, but even if that's true, IIUC only one relation's
cache entry can set in_use to true at a time. If my understanding is
correct, when the walsender accepts invalidation messages in
logicalrep_write_tuple() as you mentioned, it doesn't release the
cache of the relation whose change is being sent but does for other
relations. It seems to me too aggressive to release caches compared to
the current behavior.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2025-08-15 18:29:24 Re: memory leak in logical WAL sender with pgoutput's cachectx
Previous Message Peter Geoghegan 2025-08-15 18:05:06 Re: index prefetching