Re: collateral benefits of a crash-safe visibility map

On Tue, May 10, 2011 at 3:47 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> To address the first problem, what we've talked about doing is
> something along the line of freezing the tuples at the time we mark
> the page all-visible, so we don't have to go back and do it again
> later.  Unfortunately, it's not quite that simple, because freezing
> tuples that early would cause all sorts of headaches for hot standby,
> not to mention making Tom and Alvaro grumpy when they're trying to
> figure out a corruption problem and all the xmins are FrozenXID rather
> than whatever they were originally.  We floated the idea of a
> tuple-level bit HEAP_XMIN_FROZEN that would tell the system to treat
> the tuple as frozen, but wouldn't actually overwrite the xmin field.
> That would solve the forensic problem with earlier freezing, but it
> doesn't do anything to resolve the Hot Standby problem.  There is a
> performance issue to worry about, too: freezing operations must be
> xlog'd, as we update relfrozenxid based on the results, and therefore
> can't risk losing a freezing operation later on.  So freezing sooner
> means more xlog activity for pages that might very well never benefit
> from it (if the tuples therein don't stick around long enough for it
> to matter).

Hmmm, do we really need to WAL log freezing?

Can we break down freezing into a 2 stage process, so that we can have
first stage as a lossy operation and a second stage that is WAL
logged?

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services