On Wed, Jan 11, 2023 at 6:16 PM Hayato Kuroda (Fujitsu)
<kuroda.hayato@fujitsu.com> wrote:
>
> > 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
>
okay, I see. So even when 'wal_receiver_status_interval' is set to 0,
no log/warning is needed when the user tries to set min_apply_delay>0?
Are we good with doc alone?
One trivial correction in config.sgml:
+ terminates due to the timeout errors. Hence, make sure this parameter
+ shorter than the <literal>wal_sender_timeout</literal> of the publisher.
Hence, make sure this parameter is shorter... <is missing>
thanks
Shveta