Dear Fujii-san,

While reviewing the patch at [1], I noticed a case where lock waits on
a logical apply worker in the subscriber can cause the checkpointer on
the publisher to stall. This seems like unexpected behavior and may
need to be addressed.

The issue can occur as follows:

1. A logical apply worker on the subscriber blocks waiting for a lock.
2. Because the apply worker cannot receive further messages, the walsender's
send buffer on the publisher becomes full.
3. If the walsender then encounters a maxslotwalkeepsize error,
it attempts to send an error message to the subscriber before exiting.
However, with a full send buffer, the walsender blocks while trying to
send this message.
4. The checkpointer on the publisher calls InvalidateObsoleteReplicationSlots()
and waits for the slot to be released. Since the walsender is stuck and
the slot is not released, the checkpointer also becomes stuck.

I confirmed this could happen if the maxslotwalkeepsize is enabled
(in other words, the value is not -1).
Per my test, walsendertimeout cannot work well because the process is stuck at
the lower layer, but tcpusertimeout can terminate the process. Can we mention
the workaround in the doc instead of fixing the code?

It won't work for a Unix domain socket connection, but it's not realistic for the
production stage.