On Fri, 2006-10-27 at 12:01 -0400, Tom Lane wrote:
> "Heikki Linnakangas" <heikki@enterprisedb.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.
So we definitely have a nasty problem here.
VACUUM FREEZE is just a loaded gun right now.
> 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?
Thinking...
Also, we should probably be setting all the hint bits for pages during
recovery then, so we don't need to re-write them again later.
> Another thing I'm concerned about is the scenario where a PITR
> hot-standby machine tracks a master over a period of more than 4 billion
> transactions. I'm not sure what will happen in the slave's pg_clog
> directory, but I'm afraid it won't be good :-(
I think we'll need to error-out at that point, plus produce messages
when we pass 2 billion transactions recovered. It makes sense to produce
a new base backup regularly anyway.
We'll also need to produce an error message on the primary server so
that we take a new base backup every 2 billion transactions.
There are better solutions, but I'm not sure it makes sense to try and
fix them right now, since that could well delay the release. If we think
it is a necessary fix for the 8.2 line then we could get a better fix
into 8.2.1
[I've just coded the relcache invalidation WAL logging patch also.]
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
