pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Chao Li <li.evan.chao@gmail.com>
To: Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>
Cc: Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>
Cc: pgsql-hackers@lists.postgresql.org <pgsql-hackers@lists.postgresql.org>
Cc: shveta malik <shveta.malik@gmail.com>
Subject: Re: [bug fix] prepared transaction might be lost when max_prepared_transactions is zero on the subscriber
Date: Mon, 22 Dec 2025 17:28:37 +0800
Message-ID: <0CE4BCB2-5C74-4A4F-88FF-60D8ED2622F9@gmail.com> (raw)
In-Reply-To: <TY4PR01MB169078771FB31B395AB496A6B94B4A@TY4PR01MB16907.jpnprd01.prod.outlook.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>



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









view thread (28+ messages)  latest in thread

Message-ID: <0CE4BCB2-5C74-4A4F-88FF-60D8ED2622F9@gmail.com>
Permalink:  ../0CE4BCB2-5C74-4A4F-88FF-60D8ED2622F9@gmail.com/
Also on:    postgresql.org/message-id/0CE4BCB2-5C74-4A4F-88FF-60D8ED2622F9@gmail.com

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: li.evan.chao@gmail.com, houzj.fnst@fujitsu.com, amit.kapila16@gmail.com, kuroda.hayato@fujitsu.com, pgsql-hackers@lists.postgresql.org, shveta.malik@gmail.com
  Subject: Re: [bug fix] prepared transaction might be lost when max_prepared_transactions is zero on the subscriber
  In-Reply-To: <0CE4BCB2-5C74-4A4F-88FF-60D8ED2622F9@gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox