Re: [PATCHES] WAL logging freezing - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCHES] WAL logging freezing
Date
Msg-id 6404.1161964872@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCHES] WAL logging freezing  ("Heikki Linnakangas" <heikki@enterprisedb.com>)
Responses Re: [PATCHES] WAL logging freezing  ("Simon Riggs" <simon@2ndquadrant.com>)
Re: [PATCHES] WAL logging freezing  ("Heikki Linnakangas" <heikki@enterprisedb.com>)
Re: [PATCHES] WAL logging freezing  ("Heikki Linnakangas" <heikki@enterprisedb.com>)
List pgsql-hackers
"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.  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?

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 :-(

            regards, tom lane

pgsql-hackers by date:

Previous
From: "Heikki Linnakangas"
Date:
Subject: Re: [PATCHES] WAL logging freezing
Next
From: Peter Eisentraut
Date:
Subject: Re: bug in on_error_rollback !?