Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81\))
Subject: Re: [bug fix] prepared transaction might be lost when
 max_prepared_transactions is zero on the subscriber
From: Chao Li <li.evan.chao@gmail.com>
In-Reply-To: 
 <TY4PR01MB169078771FB31B395AB496A6B94B4A@TY4PR01MB16907.jpnprd01.prod.outlook.com>
Date: Mon, 22 Dec 2025 17:28:37 +0800
Cc: Amit Kapila <amit.kapila16@gmail.com>,
 "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>,
 "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>,
 shveta malik <shveta.malik@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <0CE4BCB2-5C74-4A4F-88FF-60D8ED2622F9@gmail.com>
References: 
 <TYAPR01MB5692FAC23BE40C69DA8ED4AFF5B92@TYAPR01MB5692.jpnprd01.prod.outlook.com>
 <CAA4eK1J8j33OrTVGRgpw9eGYsFyyT=XyLJ2eC4DpzsoggYKTDg@mail.gmail.com>
 <CAJpy0uD64yWnGsafYQU=VvuL8kVcen2iMRxf6ReRZcTtqDZ16A@mail.gmail.com>
 <OS0PR01MB5716AB0BE911D79120DDE28D94B92@OS0PR01MB5716.jpnprd01.prod.outlook.com>
 <TY4PR01MB169078771FB31B395AB496A6B94B4A@TY4PR01MB16907.jpnprd01.prod.outlook.com>
To: "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>
Archived-At: 
 <https://www.postgresql.org/message-id/0CE4BCB2-5C74-4A4F-88FF-60D8ED2622F9%40gmail.com>
Precedence: bulk


> On Dec 22, 2025, at 17:01, Zhijie Hou (Fujitsu) =
<houzj.fnst@fujitsu.com> wrote:
>=20
> Hi,
>=20
> When reviewing some parallel apply related codes, I noticed a bug in =
the
> parallel apply worker, similar to the issue discussed in this thread.
>=20
> The issue is that the logical replication parallel apply worker may =
erroneously
> advance the origin progress during an error or unsuccessful apply. =
This can lead
> to transaction loss, as these transactions will not be resent by the =
server.
> Commit 3f28b2fc addressed a similar issue in both the apply worker and =
table
> sync worker.
>=20
> The original fix involved registering a before_shmem_exit callback to =
reset the
> origin information, preventing the worker from advancing it during =
transaction
> abortion on shutdown. The attached patch registers the same callback =
for the
> parallel apply worker, ensuring consistent behavior across all =
workers.
>=20
> Best Regards,
> Hou zj
> <v1-0001-Fix-unexpected-origin-advancement-during-parallel.patch>

So, ParallelApplyWorkerMain() only calls InitializeLogRepWorker() but =
SetupApplyOrSyncWorker(), by moving before_shmem_exit() into =
InitializeLogRepWorker(), ParallelApplyWorkerMain()() gets the exit =
callback.

LGTM.

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