On Tue, May 10, 2011 at 3:47 PM, Robert Haas <robertmh...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers