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

Поиск
Список
Период
Сортировка
От Zhijie Hou (Fujitsu)
Тема RE: [bug fix] prepared transaction might be lost when max_prepared_transactions is zero on the subscriber
Дата
Msg-id TY4PR01MB169078771FB31B395AB496A6B94B4A@TY4PR01MB16907.jpnprd01.prod.outlook.com
обсуждение исходный текст
Ответ на RE: [bug fix] prepared transaction might be lost when max_prepared_transactions is zero on the subscriber  ("Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>)
Ответы Re: [bug fix] prepared transaction might be lost when max_prepared_transactions is zero on the subscriber
Re: [bug fix] prepared transaction might be lost when max_prepared_transactions is zero on the subscriber
Список 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

Вложения

В списке pgsql-hackers по дате отправления: