Re: Backward movement of confirmed_flush resulting in data duplication.
Nisha Moond <nisha.moond412@gmail.com>
From: Nisha Moond <nisha.moond412@gmail.com>
To: shveta malik <shveta.malik@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Amit Kapila <amit.kapila16@gmail.com>,
"Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>
Date: 2025-05-16T12:08:46Z
Lists: pgsql-hackers
Attachments
- reproduce_steps_for_pg14_to_16.txt (text/plain)
- reproduce_steps_for_pg13.txt (text/plain)
Hi, On Tue, May 13, 2025 at 3:48 PM shveta malik <shveta.malik@gmail.com> wrote: > > > With the given script, the problem reproduces on Head and PG17. We are > trying to reproduce the issue on PG16 and below where injection points > are not there. > The issue can also be reproduced on PostgreSQL versions 13 through 16. The same steps shared earlier in the 'reproduce_data_duplicate_without_twophase.sh' script can be used to reproduce the issue on versions PG14 to PG16. Since back branches do not support injection points, you can add infinite loops at the locations where the patch 'v1-0001-Injection-points-to-reproduce-the-confirmed_flush.patch introduces injection points'. These loops allow holding and releasing processes using a debugger when needed. Attached are detailed documents describing the reproduction steps: 1) Use 'reproduce_steps_for_pg14_to_16.txt' for PG14 to PG16. 2) Use 'reproduce_steps_for_pg13.txt' for PG13. Note: PG13 uses temporary replication slots for tablesync workers, unlike later versions that use permanent slots. Because of this difference, some debugger-related steps differ slightly in PG13, which is why a separate document is provided for it. -- Thanks, Nisha
Commits
-
Don't retreat slot's confirmed_flush LSN.
- ad5eaf390c58 18.0 landed
- 7318f241d29c 17.6 landed
- c0f51fde534d 16.10 landed
- 9d1a62359606 15.14 landed
- e68459489c20 14.19 landed
- e323d9df002d 13.22 landed