Dear Sawada-san,
Thank you for giving your consideration!
> > We have documented at least one such case
> > already where during Drop Subscription, if the network is not
> > reachable then also, a similar problem can happen and users need to be
> > careful about it [1].
>
> Apart from a bad-use case example I mentioned, in general, piling up
> WAL files due to the replication slot has many bad effects on the
> system. I'm concerned that the side effect of this feature (at least
> of the current design) is too huge compared to the benefit, and afraid
> that users might end up using this feature without understanding the
> side effect well. It might be okay if we thoroughly document it but
> I'm not sure.
One approach is that change max_slot_wal_keep_size forcibly when min_send_delay
is set. But it may lead to disable the slot because WALs needed by the time-delayed
replication may be also removed. Just the right value cannot be set by us because
it is quite depends on the min_send_delay and workload.
How about throwing the WARNING when min_send_delay > 0 but
max_slot_wal_keep_size < 0? Differ from previous, version the subscription
parameter min_send_delay will be sent to publisher. Therefore, we can compare
min_send_delay and max_slot_wal_keep_size when publisher receives the parameter.
Of course we can reject such a setup by using ereport(ERROR), but it may generate
abandoned replication slot. It is because we send the parameter at START_REPLICATION
and the slot has been already created.
Best Regards,
Hayato Kuroda
FUJITSU LIMITED
