On Thu, Mar 2, 2023 at 7:38 AM Masahiko Sawada <sawada.m...@gmail.com> wrote: > > On Wed, Mar 1, 2023 at 6:21 PM Hayato Kuroda (Fujitsu) > <kuroda.hay...@fujitsu.com> wrote: > > > > > > > > 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. > > Since max_slot_wal_keep_size can be changed by reloading the config > file, each walsender warns it also at that time? >
I think Kuroda-San wants to emit a WARNING at the time of CREATE SUBSCRIPTION. But it won't be possible to emit a WARNING at the time of ALTER SUBSCRIPTION. Also, as you say if the user later changes the value of max_slot_wal_keep_size, then even if we issue LOG/WARNING in walsender, it may go unnoticed. If we really want to give WARNING for this then we can probably give it as soon as user has set non-default value of min_send_delay to indicate that this can lead to retaining WAL on the publisher and they should consider setting max_slot_wal_keep_size. Having said that, I think users can always tune max_slot_wal_keep_size and min_send_delay (as none of these requires restart) if they see any indication of unexpected WAL size growth. There could be multiple ways to check it but I think one can refer wal_status in pg_replication_slots, the extended value can be an indicator of this. > Not sure it's > helpful. I think it's a legitimate use case to set min_send_delay > 0 > and max_slot_wal_keep_size = -1, and users might not even notice the > WARNING message. > I think it would be better to tell about this in the docs along with the 'min_send_delay' description. The key point is whether this would be an acceptable trade-off for users who want to use this feature. I think it can harm only if users use this without understanding the corresponding trade-off. As we kept the default to no delay, it is expected from users using this have an understanding of the trade-off. -- With Regards, Amit Kapila.
