> Attached the updated patch v19.
+ maybe_delay_apply(TransactionId xid, TimestampTz finish_ts)
I look this spelling strange. How about maybe_apply_delay()?
send_feedback():
+ * If the subscriber side apply is delayed (because of time-delayed
+ * replication) then do not tell the publisher that the received latest
+ * LSN is already applied and flushed, otherwise, it leads to the
+ * publisher side making a wrong assumption of logical replication
+ * progress. Instead, we just send a feedback message to avoid a publisher
+ * timeout during the delay.
*/
- if (!have_pending_txes)
+ if (!have_pending_txes && !in_delayed_apply)
flushpos = writepos = recvpos;
Honestly I don't like this wart. The reason for this is the function
assumes recvpos = applypos but we actually call it while holding
unapplied changes, that is, applypos < recvpos.
Couldn't we maintain an additional static variable "last_applied"
along with last_received? In this case the condition cited above
would be as follows and in_delayed_apply will become unnecessary.
+ if (!have_pending_txes && last_received == last_applied)
The function is a static function and always called with a variable
last_received that has the same scope with the function, as the first
parameter. Thus we can remove the first parameter then let the
function directly look at the both two varaibles instead.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center