| From: | "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com> |
|---|---|
| To: | 'Amit Kapila' <amit(dot)kapila16(at)gmail(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com> |
| Cc: | "'pgsql-hackers(at)lists(dot)postgresql(dot)org'" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, 'shveta malik' <shveta(dot)malik(at)gmail(dot)com> |
| Subject: | RE: [bug fix] prepared transaction might be lost when max_prepared_transactions is zero on the subscriber |
| Date: | 2025-12-22 09:01:19 |
| Message-ID: | TY4PR01MB169078771FB31B395AB496A6B94B4A@TY4PR01MB16907.jpnprd01.prod.outlook.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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 | Content-Type | Size |
|---|---|---|
| v1-0001-Fix-unexpected-origin-advancement-during-parallel.patch | application/octet-stream | 4.6 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Grigoriy Novikov | 2025-12-22 09:06:10 | Re: [PATCH] Add cascade synchronous replication |
| Previous Message | Peter Eisentraut | 2025-12-22 08:46:13 | Remove MsgType type |