Re: Exit walsender before confirming remote flush in logical replication

Dear pgsql-hackers,

I am also interested in solving this problem, so I suggest a patch which
is based on Hayato's work shared earlier.

The problem we are solving is that the logical walsender processes currently
do not allow postgres to shut down until receiver side confirms the flush of
all data. In case of logical replication, this is not necessary. This can lead
to an undesirable shutdown delay if, for example, apply worker is waiting for
any locks to be released.

I agree with the opinion that the default behavior of the system should not be
changed, as some clients may rely on the current behavior. But instead of
the START_REPLICATION parameter I propose a GUC parameter on the sender that
controls the walsender shutdown mode for all logical walsenders.the First,
the START_REPLICATION parameter places responsibility for choosing the sender’s
shutdown semantics on the receiver side. Second, per-subscriber settings do not
solve the problematic operational case where many walsenders exist: if even one
of N walsender processes remains configured non-immediate, the publisher can
still be blocked. In other words, setting immediate for most subscribers but
missing one does not fix the global inability to shut down.

I also attach a tap test that reproduces the apply-worker's waiting for the
release of lock and the successful shutdown of publisher in immediate walsender
shutdown mode.

Best Regards,
Andrey