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
