Re: WAL logging freezing

Tom Lane wrote:
> "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> 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