Re: Potential data loss due to race condition during logical replication slot creation
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>, "Callahan,
Drew" <callaan@amazon.com>, "pgsql-bugs@lists.postgresql.org" <pgsql-bugs@lists.postgresql.org>
Date: 2024-03-18T09:08:06Z
Lists: pgsql-bugs
On Wed, Mar 13, 2024 at 3:17 PM Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com> wrote: > > > Attached patch implemented the approach a) since no one made. I also added > > the test which can do assertion failure, but not sure it should be included. > I feel setting "needs_full_snapshot" to true for decoding means the snapshot will start tracking non-catalog committed xacts as well which is costly. See SnapBuildCommitTxn(). Can we avoid this problem if we would have list of all running xacts when we serialize the snapshot by not decoding any xact whose xid lies in that list? If so, one idea to achieve could be that we maintain the highest_running_xid while serailizing the snapshot and then during restore if that highest_running_xid is <= builder->initial_xmin_horizon, then we ignore restoring the snapshot. We already have few such cases handled in SnapBuildRestore(). -- With Regards, Amit Kapila.
Commits
-
Fix possibility of logical decoding partial transaction changes.
- bb19b70081e2 18.0 landed
- 068674f4ab44 17.0 landed
- 2f3304ce133f 16.4 landed
- aee8c2b95492 15.8 landed
- f7d3caf9ddbf 14.13 landed
- cf2c69ec5a5b 13.16 landed
- 1b370758770c 12.20 landed