Thread: Re: [COMMITTERS] pgsql: Mark vacuum_defer_cleanup_age as PGC_POSTMASTER.

Robert Haas <robertmhaas@gmail.com> writes:
> On Sat, Feb 2, 2013 at 1:55 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> Mark vacuum_defer_cleanup_age as PGC_POSTMASTER.
>> Following bug analysis of #7819 by Tom Lane

> This has barely been discussed, let alone agreed.

Well, we have a bug, and I believe everybody agrees that it can be
fixed along the lines I suggested at
http://www.postgresql.org/message-id/27553.1359764642@sss.pgh.pa.us

I agree with your complaint that this will make VACUUM a bit more
conservative than it has been, but we don't appear to have any other
workable solution proposal, certainly none that has a chance of being
ready for tomorrow's back-branch releases.  The idea of maintaining
extra state to allow more accurate database-local GetOldestXmin
calculations is worth investigating --- but it does need investigation
to find out whether it's worth the tradeoff of making GetSnapshotData
slower.  Not to mention that it seems like there's a nontrivial chance
of introducing new bugs, so that I'd prefer we only did that in HEAD
not the back branches.

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.

I also note that this isn't the first time we've been bitten by implicit
or explicit assumptions that GetOldestXmin doesn't go backwards.  See
for instance commit 93d888232e80e4d676e24fe93ae6d27459d966be, which
I wonder if we oughtn't revert once the dust settles.  So even if we had
a complete solution proposal that didn't involve preventing that, I'd be
more inclined to go in this direction.
        regards, tom lane

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