Dear Horiguchi-san,
Thank you for responding! Before modifying patches, I want to confirm something
you said.
> As Amit-K mentioned, we may need to change the name of the option in
> this version, since the delay mechanism in this version causes a delay
> in sending from publisher than delaying apply on the subscriber side.
Right, will be changed.
> I'm not sure why output plugin is involved in the delay mechanism. It
> appears to me that it would be simpler if the delay occurred in
> reorder buffer or logical decoder instead.
I'm planning to change, but..
> Perhaps what I understand
> correctly is that we could delay right before only sending commit
> records in this case. If we delay at publisher end, all changes will
> be sent at once if !streaming, and otherwise, all changes in a
> transaction will be spooled at subscriber end. In any case, apply
> worker won't be holding an active transaction unnecessarily.
What about parallel case? Latest patch does not reject the combination of parallel
streaming mode and delay. If delay is done at commit and subscriber uses an parallel
apply worker, it may acquire lock for a long time.
> Of
> course we need add the mechanism to process keep-alive and status
> report messages.
Could you share the good way to handle keep-alive and status messages if you have?
If we changed to the decoding layer, it is strange to call walsender function
directly.
> Those setups work fine when no
> apply-delay involved, but they won't work with the patches we're
> talking about because the subscriber won't respond to the keep-alive
> packets from the peer. So when I wrote "practically works" in the
> last mail, this is what I meant.
I'm not sure around the part. I think in the latest patch, subscriber can respond
to the keepalive packets from the peer. Also, publisher can respond to the peer.
Could you please tell me if you know a case that publisher or subscriber cannot
respond to the opposite side? Note that if we apply the publisher-side patch, we
don't have to apply subscriber-side patch.
Best Regards,
Hayato Kuroda
FUJITSU LIMITED
