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-22T11:09:27Z

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:28, Chao Li <li.evan.chao@gmail.com> wrote:
> 
> 
> 
>> 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.
> 

I just noticed a nitpick while reviewing the other your patch:
```
+	 * avoid origin advancement for an in-complete transaction which could
```

“In-complete” should be just “incomplete”.

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