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 max_slot_wal_keep_size 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 max_slot_wal_keep_size is enabled
(in other words, the value is not -1).
Per my test, wal_sender_timeout cannot work well because the process is stuck at
the lower layer, but tcp_user_timeout 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.
Best regards,
Hayato Kuroda
FUJITSU LIMITED
