Re: Track in pg_replication_slots the reason why slots conflict?

Поиск
Список
Период
Сортировка
От Isaac Morland
Тема Re: Track in pg_replication_slots the reason why slots conflict?
Дата
Msg-id CAMsGm5eHWDQ4SHx2k41DvGpA2BqSm7swhPwwRMr6rhWMk054NA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Track in pg_replication_slots the reason why slots conflict?  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: Track in pg_replication_slots the reason why slots conflict?  (shveta malik <shveta.malik@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Nazir Bilal Yavuz
Дата:
Сообщение: Re: Show WAL write and fsync stats in pg_stat_io
Следующее
От: Umair Shahid
Дата:
Сообщение: Update docs for default value of fdw_tuple_cost