On Tue, Dec 26, 2023 at 7:35 PM Isaac Morland <isaac.morl...@gmail.com> wrote: > > On Thu, 21 Dec 2023 at 09:26, Amit Kapila <amit.kapil...@gmail.com> wrote: > >> >> A conflicting column where NULL indicates no conflict, and other >> > values indicate the reason for the conflict, doesn't seem too bad. >> > >> >> This is fine too. > > > I prefer this option. There is precedent for doing it this way, for example > in pg_stat_activity.wait_event_type. > > The most common test of this field is likely to be "is there a conflict" and > it's better to write this as "[fieldname] IS NOT NULL" than to introduce a > magic constant. Also, it makes clear to future maintainers that this field > has one purpose: saying what type of conflict there is, if any. If we find > ourselves wanting to record a new non-conflict status (no idea what that > could be: "almost conflict"? "probably conflict soon"?) there would be less > temptation to break existing tests for "is there a conflict".
+1 on using "[fieldname] IS NOT NULL" to find "is there a conflict" PFA the patch which attempts to implement this. This patch changes the existing 'conflicting' field to 'conflicting_cause' in pg_replication_slots. This new field is always NULL for physical slots (like the previous field conflicting), as well as for those logical slots which are not invalidated. thanks Shveta
v1-0001-Track-conflicting_cause-in-pg_replication_slots.patch
Description: Binary data
