| From: | "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com> |
|---|---|
| To: | 'Nisha Moond' <nisha(dot)moond412(at)gmail(dot)com>, shveta malik <shveta(dot)malik(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com> |
| Subject: | RE: Fix resource leak in FindConflictTuple() retry path |
| Date: | 2026-09-03 07:33:18 |
| Message-ID: | OS9PR01MB121493621DA82E8D82FF9C9DEF5B62@OS9PR01MB12149.jpnprd01.prod.outlook.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Dear Nisha,
Not sure, should we release a buffer pin if should_refetch_tuple() returns true?
I referred heapam_tuple_lock()/heap_lock_tuple(), they pin a buffer via ReadBuffer()
and transfers to a slot via ExecStorePinnedBufferHeapTuple().
IIUC, ExecClearTuple() can release corresponding resources for the slot, so below
fix is enough.
```
--- a/src/backend/executor/execReplication.c
+++ b/src/backend/executor/execReplication.c
@@ -268,7 +268,10 @@ retry:
PopActiveSnapshot();
if (should_refetch_tuple(res, &tmfd))
+ {
+ ExecClearTuple(*conflictslot);
goto retry;
+ }
```
Best regards,
Hayato Kuroda
FUJITSU LIMITED
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Nestorov | 2026-09-03 07:40:54 | Re: gist_trgm_ops '=' operator: planner picks it over btree, ~300x slower |
| Previous Message | Nisha Moond | 2026-09-03 07:24:54 | Re: Crashes on a partition whose concurrent detach never finished |