Re: Fix a relcache reference leak in reorderbuffer.c

> On Aug 19, 2026, at 06:35, 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. 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.
> --
> Michael

I just took a deeper look at the code. If we handle the continue defensively, then in theory nrelations could be 0. We should also defensively skip ReorderBufferApplyTruncate() when nrelations == 0. Looking at a callback function, for example, pgoutput_truncate() in src/backend/replication/pgoutput/pgoutput.c appears to assume that nrelations > 0, it doesn't specially handle nrelations == 0.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/