On 2013-05-30 14:39:46 -0400, Robert Haas wrote: > > Since we're not storing 64-bit wide XIDs on every tuple, we'd still need to > > replace the XIDs with FrozenXid whenever the difference between the smallest > > and largest XID on a page exceeds 2^31. But that would only happen when > > you're updating the page, in which case the page is dirtied anyway, so it > > wouldn't cause any extra I/O. > > It would cause some extra WAL activity, but it wouldn't dirty the page > an extra time.
You probably could do it similarly to how we currently do XLOG_HEAP_ALL_VISIBLE_CLEARED and just recheck the page on replay. The insert/update/delete record will already contain a FPI if necessary, so that should be safe. > > This would also be the first step in allowing the clog to grow larger than 2 > > billion transactions, eliminating the need for anti-wraparound freezing > > altogether. You'd still want to truncate the clog eventually, but it would > > be nice to not be pressed against the wall with "run vacuum freeze now, or > > the system will shut down". > Interesting. That seems like a major advantage. Hm. Why? If freezing gets notably cheaper I don't really see much need for keeping that much clog around? If we still run into anti-wraparound areas, there has to be some major operational problem. Greetings, Andres Freund -- Andres Freund 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
