Dear Andres and other hackers,
> OTOH, if we want to implement the functionality on publisher-side,
> I think we need to first consider the interface.
> We can think of two options (a) Have it as a subscription parameter as the patch
> has now and
> then pass it as an option to the publisher which it will use to delay;
> (b) Have it defined on publisher-side, say via GUC or some other way.
> The basic idea could be that while processing commit record (in DecodeCommit),
> we can somehow check the value of delay and then use it there to delay sending
> the xact.
> Also, during delay, we need to somehow send the keepalive and process replies,
> probably via a new callback or by some existing callback.
> We also need to handle in-progress and 2PC xacts in a similar way.
> For the former, probably we would need to apply the delay before sending the first
> stream.
> Could you please share what you feel on this direction as well ?
I implemented a patch that the delaying is done on the publisher side. In this patch,
approach (a) was chosen, in which min_apply_delay is specified as a subscription
parameter, and then apply worker passes it to the publisher as an output plugin option.
During the delay, the walsender periodically checks and processes replies from the
apply worker and sends keepalive messages if needed. Therefore, the ability to handle
keepalives is not loosed.
To delay the transaction in the output plugin layer, the new LogicalOutputPlugin
API was added. For now, I choose the output plugin layer but can consider to do
it from the core if there is a better way.
Could you please share your opinion?
Note: thanks for Osumi-san to help implementing.
Best Regards,
Hayato Kuroda
FUJITSU LIMITED