Re: Track in pg_replication_slots the reason why slots conflict?
От | Andres Freund |
---|---|
Тема | Re: Track in pg_replication_slots the reason why slots conflict? |
Дата | |
Msg-id | 20231221094015.bsrblo55laak7vhy@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Track in pg_replication_slots the reason why slots conflict? (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Track in pg_replication_slots the reason why slots conflict?
|
Список | pgsql-hackers |
Hi, On 2023-12-21 09:21:04 +0900, Michael Paquier wrote: > While listening at Bertrand's talk about logical decoding on standbys > last week at Prague, I got surprised by the fact that we do not > reflect in the catalogs the reason why a conflict happened for a slot. > There are three of them depending on ReplicationSlotInvalidationCause: > - WAL removed. > - Invalid horizon. > - Insufficient WAL level. It should be extremely rare to hit any of these other than "WAL removed", so I'm not sure it's worth adding interface complexity to show them. > ReplicationSlotCtl holds this information, so couldn't it be useful > for monitoring purposes to know why a slot got invalidated and add a > column to pg_get_replication_slots()? This could just be an extra > text conflicting_reason, defaulting to NULL when there's nothing to > see. Extra columns aren't free from a usability perspective. IFF we do something, I think it should be a single column with a cause. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: