On Mon, Jun 13, 2011 at 04:16:06PM +0100, Simon Riggs wrote: > On Mon, Jun 13, 2011 at 3:11 AM, Robert Haas <robertmh...@gmail.com> wrote: > > On Sun, Jun 12, 2011 at 3:01 PM, Noah Misch <n...@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
repro-btree-reuse-feedback.sh
Description: Bourne shell script
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
