apply worker misses closing partition leaves

From: "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>
To: "'pgsql-hackers(at)lists(dot)postgresql(dot)org'" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>
Subject: apply worker misses closing partition leaves
Date: 2026-08-17 11:53:27
Message-ID: OS9PR01MB121491E7E05950D108AF9A6D8F5A72@OS9PR01MB12149.jpnprd01.prod.outlook.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dear hackers,
(CC: David, who is a committer for 39dcfda)

While working on the parallel apply, I found that 013_partition.pl raises WARNINGs
like [1]. Per my research it happened after the 39dcfda. The warning indicates the
partition leaf opened by the worker is not expressly closed.

IIUC, it can happen if partition leaves have after triggers. The apply worker
has to obtain ResultRelInfo for the relation in
finish_edata()->AfterTriggerEndQuery()->ExecGetTriggerResultRel(), and it firstly
checks the cached result in EState::es_opened_result_relations.
The commit 39dcfda made the condition for re-use the cache stricter (requires
matching rootRelInfo as well) and the apply worker could not match the condition.
In this case the relation would be opened but nobody close: the resource
owner finally handles it.

IIUC, the difference between normal and partition leaves is how they are cached
in es_tuple_routing_result_relations. Normal relations are stored with
ResultRelInfo::ri_RootResultRelInfo = NULL, and partition ones have valid value.
afterTriggerInvokeEvents() always passes rootRelInfo = NULL, so only leaves
miss the cache.

I'm not familiar with codes around triggers. But if we try to fix on logical
replication side, relations opened for triggers can be closed in finish_edata().
See attached.

[1]:
```
2026-08-17 18:12:41.780 JST logical replication apply worker[150182] WARNING: resource was not closed: relation "tab1_2_2"
2026-08-17 18:12:41.780 JST logical replication apply worker[150182] CONTEXT: processing remote data for replication origin "pg_16438" during message type "COMMIT" in transaction 707, finished at 0/017E3E50
```

Best regards,
Hayato Kuroda
FUJITSU LIMITED

Attachment Content-Type Size
0001-Close-relations-opened-for-AFTER-trigger.patch application/octet-stream 1.5 KB

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Bapat 2026-08-17 11:56:56 Re: Changing shared_buffers without restart
Previous Message Matthias van de Meent 2026-08-17 11:36:29 Re: Thread-safe stringToNode() / pg_strtok()