Re: [bug fix] prepared transaction might be lost when max_prepared_transactions is zero on the subscriber - Mailing list pgsql-hackers

From Chao Li
Subject Re: [bug fix] prepared transaction might be lost when max_prepared_transactions is zero on the subscriber
Date
Msg-id B8C4045C-860A-4F1C-B5F2-8846843181CC@gmail.com
Whole thread Raw
In response to Re: [bug fix] prepared transaction might be lost when max_prepared_transactions is zero on the subscriber  (Chao Li <li.evan.chao@gmail.com>)
List pgsql-hackers

> 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/







pgsql-hackers by date:

Previous
From: shveta malik
Date:
Subject: Re: Proposal: Conflict log history table for Logical Replication
Next
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: Parallel Apply