Re: Fix a relcache reference leak in reorderbuffer.c

Hi Michael,

On Wed, Aug 19, 2026 at 6:35 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Tue, Aug 18, 2026 at 01:59:01PM +0800, Xuneng Zhou wrote:
> > I think this is not a session-level *leak*. The resource owner of
> > ongoing txn would take care of the reference once the
> > ReorderBufferProcessTXN aborts its internal transaction. Yeah, it
> > could be more troublesome if the skipped references keep accumulating
> > until the decoding of txn finishes. That said, it's not very clear to
> > me whether this code is actually excerised. Can you provide a
> > reproducer or a test?
>
> More to the point, looking at code paths producing XLOG_HEAP_TRUNCATE
> records in core, we specifically discard any relation that does not
> satisfy RelationIsLogicallyLogged().
>
> In short, it is not possible in practice to reach this code at all.
> We would do a decoding of the generated record after an historical
> snapshot, so something like a SET UNLOGGED should not be seen in
> practice.

Thanks for clarifying and confirming it.

I think that it does not hurt to be defensive in practice
> here, still I am wondering about code outside of core that may play it
> unfair, even if the consequences are minimal.

Yeah, I agree that this code still seems fragile and better to be
harnessed. The code of patch v1 LGTM.

--
Regards,
Xuneng Zhou
HighGo Software Co., Ltd.