Re: Track in pg_replication_slots the reason why slots conflict? - Mailing list pgsql-hackers

From Isaac Morland
Subject Re: Track in pg_replication_slots the reason why slots conflict?
Date
Msg-id CAMsGm5eHWDQ4SHx2k41DvGpA2BqSm7swhPwwRMr6rhWMk054NA@mail.gmail.com
Whole thread Raw
In response to Re: Track in pg_replication_slots the reason why slots conflict?  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Track in pg_replication_slots the reason why slots conflict?
List pgsql-hackers
On Thu, 21 Dec 2023 at 09:26, Amit Kapila <amit.kapila16@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".

pgsql-hackers by date:

Previous
From: Nazir Bilal Yavuz
Date:
Subject: Re: Show WAL write and fsync stats in pg_stat_io
Next
From: Umair Shahid
Date:
Subject: Update docs for default value of fdw_tuple_cost