RE: Fix 035_standby_logical_decoding.pl race conditions
Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>
From: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
To: 'Amit Kapila' <amit.kapila16@gmail.com>, Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Date: 2025-04-03T05:34:10Z
Lists: pgsql-hackers
Attachments
- v5-PG16-0001-Stabilize-035_standby_logical_decoding.pl.patch (application/octet-stream) patch v5-0001
- v5-PG17-0001-Stabilize-035_standby_logical_decoding.pl.patch (application/octet-stream) patch v5-0001
- 0001-Fix-invalid-referring-of-hash-ref-for-replication-sl.patch (application/octet-stream) patch 0001
Dear Bertrand, Amit, > > I do prefer v5-PG17-2 as it is "closer" to HEAD. That said, I think that we should > > keep the slots active and only avoid doing the checks for them (they are > invalidated > > that's fine, they are not that's fine too). > > > > I don't mind doing that, but there is no benefit in making slots > active unless we can validate them. And we will end up adding some > more checks, as in function check_slots_conflict_reason without any > advantage. I feel Kuroda-San's second patch is simple, and we have > fewer chances to make mistakes and easy to maintain in the future as > well. I have concerns for Bertrand's patch that it could introduce another timing issue. E.g., if the activated slots are not invalidated, dropping slots is keep being activated so the dropping might be fail. I did not reproduce this but something like this can happen if we activate slots. Attached patch has a conclusion of these discussions, slots are created but it seldomly be activated. Naming of patches are bit different, but please ignore... Best regards, Hayato Kuroda FUJITSU LIMITED
Commits
-
Stabilize 035_standby_logical_decoding.pl.
- 105b2cb33617 18.0 landed
- 17a165d60f73 17.5 landed
- 86392e8827d8 16.9 landed