Re: Track in pg_replication_slots the reason why slots conflict?

On Tue, Dec 26, 2023 at 7:35 PM Isaac Morland <isaac(dot)morland(at)gmail(dot)com> wrote:
>
> On Thu, 21 Dec 2023 at 09:26, Amit Kapila <amit(dot)kapila16(at)gmail(dot)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