Skip site navigation (1) Skip section navigation (2)

Re: WAL logging freezing

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, pgsql-patches(at)postgresql(dot)org
Subject: Re: WAL logging freezing
Date: 2006-10-27 16:01:12
Message-ID: 6404.1161964872@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
"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?

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

In response to

Responses

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2006-10-27 16:49:34
Subject: Re: bug in on_error_rollback !?
Previous:From: Heikki LinnakangasDate: 2006-10-27 15:44:52
Subject: Re: WAL logging freezing

pgsql-patches by date

Next:From: Tom LaneDate: 2006-10-27 16:53:52
Subject: Re: BUG #2724: Could not check connection status with "ssl=on"
Previous:From: Heikki LinnakangasDate: 2006-10-27 15:44:52
Subject: Re: WAL logging freezing

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group