| From: | Isaac Morland <isaac(dot)morland(at)gmail(dot)com> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, shveta malik <shveta(dot)malik(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> |
| Subject: | Re: Track in pg_replication_slots the reason why slots conflict? |
| Date: | 2023-12-26 14:05:10 |
| Message-ID: | CAMsGm5eHWDQ4SHx2k41DvGpA2BqSm7swhPwwRMr6rhWMk054NA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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".
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Umair Shahid | 2023-12-26 15:29:50 | Update docs for default value of fdw_tuple_cost |
| Previous Message | Nazir Bilal Yavuz | 2023-12-26 12:35:52 | Re: Show WAL write and fsync stats in pg_stat_io |