On Thu, Feb 17, 2011 at 4:30 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> Hot Standby feedback for avoidance of cleanup conflicts on standby.
> Standby optionally sends back information about oldestXmin of queries
> which is then checked and applied to the WALSender's proc->xmin.
> GetOldestXmin() is modified slightly to agree with GetSnapshotData(),
> so that all backends on primary include WALSender within their snapshots.
> Note this does nothing to change the snapshot xmin on either master or
> standby. Feedback piggybacks on the standby reply message.
> vacuum_defer_cleanup_age is no longer used on standby, though parameter
> still exists on primary, since some use cases still exist.
I have another comments about this change.
Something like the following description should be in the doc.
hot_standby_feedback has no effect if either hot_standby is off or wal_receiver_status_interval is zero.
+ if (MyProc->xmin != newxmin)
+ {
+ LWLockAcquire(ProcArrayLock, LW_SHARED);
+ MyProc->xmin = newxmin;
+ LWLockRelease(ProcArrayLock);
ProcArrayLock should be taken with LW_EXCLUSIVE since the shared
variable is changed. No?
What about exposing the feedback xid and epoch in pg_stat_replication?
It's useful when we investigate which standby unexpectedly prevents
VACUUM on the primary.
It seems too aggressive to calculate the oldest xmin and return it for
each WAL write and flush on the standby. I think this because calculation
of the oldest xmin is not light operation especially when there are many
concurrent backends. How about feeding back the xmin only when the
interval has passed?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center