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

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sat, Feb 2, 2013 at 1:55 PM, Simon Riggs <simon(at)2ndquadrant(dot)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