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
