On Mon, Jun 13, 2011 at 04:16:06PM +0100, Simon Riggs wrote:
> On Mon, Jun 13, 2011 at 3:11 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> > On Sun, Jun 12, 2011 at 3:01 PM, Noah Misch <noah@leadboat.com> wrote:
> >> Assuming that conclusion, I do think it's worth starting
> >> with something simple, even if it means additional bloat on the master in the
> >> wal_level=hot_standby + vacuum_defer_cleanup_age / hot_standby_feedback case.
> >> In choosing those settings, the administrator has taken constructive steps to
> >> accept master-side bloat in exchange for delaying recovery conflict. ?What's
> >> your opinion?
> >
> > I'm pretty disinclined to go tinkering with 9.1 at this point, too.
>
> Not least because a feature already exists in 9.1 to cope with this
> problem: hot standby feedback.
A standby's receipt of an XLOG_BTREE_REUSE_PAGE record implies that the
accompanying latestRemovedXid preceded or equaled the master's RecentXmin at the
time of issue (see _bt_page_recyclable()). Neither hot_standby_feedback nor
vacuum_defer_cleanup_age affect RecentXmin. Therefore, neither facility delays
conflicts arising directly from B-tree page reuse. See attached test script,
which yields a snapshot conflict despite active hot_standby_feedback.
Thanks,
nm