On 2013-12-14 20:19:11 +0000, Greg Stark wrote:
> I don't have a source tree handy but iirc we treaty 2^31 values as being in
> the past and 2^31 values as being in the future.
>
> I've been trying to think how to protect better against the recent vacuum
> freeze bug. If someone ruins vacuum freeze now and has any wrapped values
> they'll destroy their possibly recoverable data.
Fortunately that's exceedingly unlikely to happen. There's basically two
consequences the bug can have:
a) we don't freeze tuples on pages that are already marked all-visible because we're doing a partial scan and thus
don'tscan them.
b) (9.2+) we don't freeze tuples on a page not marked all visible, because a buffer is pinned and we skip those when
!scan_all.
a) can lead to the tuple vanishing again because they are reported as
being in progress, after 2^31 xids passed. But by virtue of being on an
all-visible page, they are fully hinted. Which means, that after the
wraparound they will be reported as delete-in-progress or
insert-in-progress. Luckily neither will get vacuumed away. They will
"just" be invisible.
What can happen with b) is that the clog gets truncated to somewhere
between the real relfrozenxid and the computed relfrozenxid. In that
case we'll get errors when later doing a
HeapTupleSatisfiesVacuum/HTSMVCC. But it's quite likely that the tuple
will get vacuumed at some point before 2^31 xids have passed since its
not marked all visible and thus will be scanned with each future vacuum.
So, for the data to be removed permanently you'd have to hit b) with
partial vacuums (scan_all vacuums do wait!) several times in a row. That
seems unlikely.
> It seems to me we shouldn't really need 2^31 values in the future. If
> vacuum or hot pruning comes across an xid far in the future, say a million
> xids further into the future than the most recent transaction, then it
> should signal an error rather than just treat it as being in the future.
Yea, I have wondered about that as well.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services