On 3 February 2013 17:53, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I think what we need to do in the short run is to fix GetOldestXmin per
> my proposal and shut off on-the-fly changes of vacuum_defer_cleanup_age.
> That will at least fix bug #7819 for cases not involving hot-standby
> feedback. Simon seems to think it's relatively easy to prevent
> walsenders from letting their advertised xmin go backwards as well,
> though from what I understood of that sub-thread it sounded more
> complicated than what I'd originally had in mind. We might be best
> advised to fix that aspect only in HEAD. I think curing the bug for
> cases not involving hot-standby feedback is still worth doing, though.
That's not quite what Andres and I discussed, but it is relatively
easy for a walsender to avoid advertising a value that goes backwards
at any point.
OTOH if you prevent GetOldestXmin() from going backwards then that
will do that implicitly since the GetOldestXmin() value on standby
won't go backwards and so the value sent to master won't go backwards
either, so it seems best to avoid additional walsender code.
If we avoid having GetOldestXmin() go backwards this will allow query
cancellations during the period initially after HS startup, since it
will initially be working with older data. As Andres observed, even if
we delay startup that would still be a problem when a standby
reconnects. I'm still thinking what to do about that.
-- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
