RE: Time delayed LR (WAS Re: logical replication restrictions)

Поиск
Список
Период
Сортировка
От Hayato Kuroda (Fujitsu)
Тема RE: Time delayed LR (WAS Re: logical replication restrictions)
Дата
Msg-id TYAPR01MB58668045912B1B1106B13FC0F5FC9@TYAPR01MB5866.jpnprd01.prod.outlook.com
обсуждение исходный текст
Ответ на Re: Time delayed LR (WAS Re: logical replication restrictions)  (shveta malik <shveta.malik@gmail.com>)
Ответы Re: Time delayed LR (WAS Re: logical replication restrictions)  (shveta malik <shveta.malik@gmail.com>)
Список pgsql-hackers
> 2.
> I think users can set ' wal_receiver_status_interval ' to 0 or more
> than 'wal_sender_timeout'. But is this a frequent use-case scenario or
> do we see DBAs setting these in such a way by mistake? If so, then I
> think, it is better to give Warning message in such a case when a user
> tries to create or alter a subscription with a large 'min_apply_delay'
> (>=  'wal_sender_timeout') , rather than leaving it to the user's
> understanding that WalSender may repeatedly timeout in such a case.
> Parse_subscription_options and AlterSubscription can be modified to
> log a warning. Any thoughts?

Yes, DBAs may set wal_receiver_status_interval to more than wal_sender_timeout by
mistake.

But to handle the scenario we must compare between min_apply_delay *on subscriber*
and wal_sender_timeout *on publisher*. Both values are not transferred to opposite
sides, so the WARNING cannot be raised. I considered that such a mechanism seemed
to be complex. The discussion around [1] may be useful.

[1]: https://www.postgresql.org/message-id/CAA4eK1Lq%2Bh8qo%2BrqGU-E%2BhwJKAHYocV54y4pvou4rLysCgYD-g%40mail.gmail.com

Best Regards,
Hayato Kuroda
FUJITSU LIMITED


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Hayato Kuroda (Fujitsu)"
Дата:
Сообщение: RE: Time delayed LR (WAS Re: logical replication restrictions)
Следующее
От: "Hayato Kuroda (Fujitsu)"
Дата:
Сообщение: RE: Time delayed LR (WAS Re: logical replication restrictions)