At Thu, 30 Sep 2021 17:07:08 +0530, Amit Kapila <amit.kapila16@gmail.com> wrote in
> On Thu, Sep 30, 2021 at 1:26 PM Kyotaro Horiguchi
> <horikyota.ntt@gmail.com> wrote:
> > If the comment describes the objective correctly, the only possible
> > impact would be that there may be a case where server responds a bit
> > slowly for a shutdown request. But I'm not sure it is definitely
> > true.
> >
>
> So, we should try to find how wal sender shutdown is dependent on
> sending keep alive and second thing is what about sync rep case? I
> think in the worst case that also might delay. Why do you think that
> would be acceptable?
Mmm. AFAICS including the history of the code, the problem to fix
looks like to be pthat logical wal receiver doesn't send a flush
response spontaneously. As far as receiver doesn't do that and unless
we allow some delay of the response, sender inevitably needs to ping
frequently until the wanted respons returns.
It seems to me that it is better to make the receiver send a response
at flush LSN movement spontaneously rather than tweaking the keepalive
sending mechanism. But letting XLogFlush trigger lsn_mapping
processing does not seem simple..
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center