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

From Zhijie Hou (Fujitsu)
Subject RE: [bug fix] prepared transaction might be lost when max_prepared_transactions is zero on the subscriber
Date
Msg-id TY4PR01MB169078771FB31B395AB496A6B94B4A@TY4PR01MB16907.jpnprd01.prod.outlook.com
Whole thread Raw
In response to RE: [bug fix] prepared transaction might be lost when max_prepared_transactions is zero on the subscriber  ("Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>)
Responses Re: [bug fix] prepared transaction might be lost when max_prepared_transactions is zero on the subscriber
List pgsql-hackers
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

Attachment

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Remove MsgType type
Next
From: Grigoriy Novikov
Date:
Subject: Re: [PATCH] Add cascade synchronous replication