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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2006-10-27 16:49:34 | Re: bug in on_error_rollback !? |
Previous Message | Heikki Linnakangas | 2006-10-27 15:44:52 | Re: WAL logging freezing |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-10-27 16:53:52 | Re: BUG #2724: Could not check connection status with "ssl=on" |
Previous Message | Heikki Linnakangas | 2006-10-27 15:44:52 | Re: WAL logging freezing |