Hi, On 2023-02-11 05:44:47 +0000, Takamichi Osumi (Fujitsu) wrote: > On Saturday, February 11, 2023 11:10 AM Andres Freund <and...@anarazel.de> > wrote: > > Has there been any discussion about whether this is actually best > > implemented on the client side? You could alternatively implement it on the > > sender. > > > > That'd have quite a few advantages, I think - you e.g. wouldn't remove the > > ability to *receive* and send feedback messages. We'd not end up filling up > > the network buffer with data that we'll not process anytime soon. > Thanks for your comments ! > > We have discussed about the publisher side idea around here [1] > but, we chose the current direction. Kindly have a look at the discussion. > > If we apply the delay on the publisher, then > it can lead to extra delay where we don't need to apply. > The current proposed approach can take other loads or factors > (network, busyness of the publisher, etc) into account > because it calculates the required delay on the subscriber.
I don't think it's OK to just loose the ability to read / reply to keepalive messages. I think as-is we seriously consider to just reject the feature, adding too much complexity, without corresponding gain. Greetings, Andres Freund
