Re: Fix a relcache reference leak in reorderbuffer.c

Hi Evan,

On Tue, Aug 18, 2026 at 11:52 AM Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
>
> Hi,
>
> While working on a feature patch that I’m going to post soon, I noticed a small issue in reorderbuffer.c. In the REORDER_BUFFER_CHANGE_TRUNCATE branch of ReorderBufferProcessTXN(), some opened relations might be skipped without being closed, leading to leaked relcache references.
>
> The relevant code is:
> ```
> relations = palloc0_array(Relation, nrelids);
> for (i = 0; i < nrelids; i++)
> {
> Oid relid = change->data.truncate.relids[i];
> Relation rel;
>
> rel = RelationIdGetRelation(relid);
>
> if (!RelationIsValid(rel))
> elog(ERROR, "could not open relation with OID %u", relid);
>
> if (!RelationIsLogicallyLogged(rel))
> continue; <===== it should close rel before skipping it
>
> relations[nrelations++] = rel;
> }
>
> /* Apply the truncate. */
> ReorderBufferApplyTruncate(rb, txn, nrelations,
> relations, change,
> streaming);
>
> for (i = 0; i < nrelations; i++)
> RelationClose(relations[i]);
> ```
>
> In the loop, each relation that is appended to relations is closed after the loop. However, when RelationIsLogicallyLogged(rel) returns false, the relation is skipped without being closed, causing the leak.
>
> The attached patch makes a small fix to close the relation before continuing.

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?

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