Re: Skipping logical replication transactions on subscriber side
В списке pgsql-hackers по дате отправления:
| От | Peter Eisentraut |
|---|---|
| Тема | Re: Skipping logical replication transactions on subscriber side |
| Дата | |
| Msg-id | bd954841-596d-c212-9a13-6f9747cc8903@enterprisedb.com обсуждение исходный текст |
| Ответ на | Re: Skipping logical replication transactions on subscriber side (Amit Kapila <amit.kapila16@gmail.com>) |
| Ответы |
Re: Skipping logical replication transactions on subscriber side
|
| Список | pgsql-hackers |
On 27.05.21 12:04, Amit Kapila wrote: >>> Also, I am thinking that instead of a stat view, do we need >>> to consider having a system table (pg_replication_conflicts or >>> something like that) for this because what if stats information is >>> lost (say either due to crash or due to udp packet loss), can we rely >>> on stats view for this? >> Yeah, it seems better to use a catalog. >> > Okay. Could you store it shared memory? You don't need it to be crash safe, since the subscription will just run into the same error again after restart. You just don't want it to be lost, like with the statistics collector.
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера