Re: [bug fix] prepared transaction might be lost when max_prepared_transactions is zero on the subscriber

Chao Li <li.evan.chao@gmail.com>

From: Chao Li <li.evan.chao@gmail.com>

To: "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>

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>

Date: 2025-12-22T09:28:37Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Don't advance origin during apply failure.
- 1528b0d899d6 19 (unreleased) landed
- 2f7ffe124a9b 18.2 landed
- 63a65adf4d8e 16.12 landed
- 0ed8f1afb15f 17.8 landed
- 3f28b2fcac33 18.0 landed
- 915aafe82a7c 17.0 landed
- b39c5272c1d2 16.5 landed
Perform apply of large transactions by parallel workers.
- 216a784829c2 16.0 cited


> On Dec 22, 2025, at 17:01, Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com> wrote:
> 
> Hi,
> 
> When reviewing some parallel apply related codes, I noticed a bug in the
> parallel apply worker, similar to the issue discussed in this thread.
> 
> 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.
> 
> 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.
> 
> 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/