Hi Evan, On Tue, Aug 18, 2026 at 11:52 AM Chao Li <[email protected]> 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.
