Re: Conflict detection for update_deleted in logical replication - Mailing list pgsql-hackers

From shveta malik
Subject Re: Conflict detection for update_deleted in logical replication
Date
Msg-id CAJpy0uBJ32khb3x6RsWSVrXgEWQx=w0pc=zxKA2aPOCb2eNYgA@mail.gmail.com
Whole thread Raw
In response to Re: Conflict detection for update_deleted in logical replication  (Amit Kapila <amit.kapila16@gmail.com>)
Responses RE: Conflict detection for update_deleted in logical replication
List pgsql-hackers
One concern:

  if (should_stop_conflict_info_retention(rdt_data))
+ {
+ /*
+ * Stop retention if not yet. Otherwise, reset to the initial phase to
+ * retry all phases. This is required to recalculate the current wait
+ * time and resume retention if the time falls within
+ * max_retention_duration.
+ */
+ if (MySubscription->retentionactive)
+ rdt_data->phase = RDT_STOP_CONFLICT_INFO_RETENTION;
+ else
+ reset_retention_data_fields(rdt_data);
+
  return;
+ }

 Instead of above code changes, shall we have:

 if (should_stop_conflict_info_retention(rdt_data))
     rdt_data->phase = RDT_STOP_CONFLICT_INFO_RETENTION;  (always)

And then stop_conflict_info_retention() should have these checks:

if (MySubscription->retentionactive)
{
    ...update flag and perform stop (current functionality)
}
else
{
        Assert(!TransactionIdIsValid(MyLogicalRepWorker->oldest_nonremovable_xid));
        reset_retention_data_fields(rdt_data);
}

thanks
Shveta



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Conflict detection for update_deleted in logical replication
Next
From: Shubham Khanna
Date:
Subject: Re: Add support for specifying tables in pg_createsubscriber.