Tom Lane wrote:
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
I think it's premature to start writing
patches until we've decided how this really needs to work.
Not logging hint-bit updates seems safe to me. As long as we have the
clog, the hint-bit is just a hint. The problem with freezing is that
after freezing tuples, the corresponding clog page can go away.
Actually clog can go away much sooner than that, at least in normal
operation --- that's what datvacuumxid is for, to track where we can
truncate clog. Maybe it's OK to say that during WAL replay we keep it
all the way back to the freeze horizon, but I'm not sure how we keep the
system from wiping clog it still needs right after switching to normal
operation. Maybe we should somehow not xlog updates of datvacuumxid?
Oh, I just understood what you were trying to say. We really don't keep
clog around all the way back to the freeze horizon.
Well, how about doing just that? With a FreezeLimit of 1 billion
transactions, that's 128 megabytes of clog. We could freeze more
aggressively to make it less.
We can't just not xlog updates of datvacuumxid, because that buffer
might still be written to disk before all the hint-bit updates. One
trick would be to include the old value in the WAL record. WAL recovery
would have to keep track of those records, and reset any datvacuumxid to
the old value if there's no checkpoint record afterwards.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
