Dear Horiguchi-san, Thank you for replying! This direction seems OK, so I started to revise the patch. PSA new version.
> > > 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.. > > Yeah, I don't think we've made up our minds about which way to go yet, > so it's a bit too early to work on that. The parameter name is changed to min_send_delay. And the delaying spot is changed to logical decoder. > > > 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. > > I didn't looked too closely, but my guess is that transactions are > conveyed in spool files in parallel mode, with each file storing a > complete transaction. Based on the advice, I moved the delaying to DecodeCommit(). And the combination of parallel streaming mode and min_send_delay is rejected again. > > > 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. > > I'm sorry, but I don't have a concrete idea at the moment. When I read > through the last patch, I missed that WalSndDelay is actually a subset > of WalSndLoop. Although it can handle keep-alives correctly, I'm not > sure we can accept that structure.. No issues. I have kept the current implementation. Some bugs I found are also fixed. Best Regards, Hayato Kuroda FUJITSU LIMITED
v2-0001-Time-delayed-logical-replication-on-publisher-sid.patch
Description: v2-0001-Time-delayed-logical-replication-on-publisher-sid.patch
