Had an interesting situation recently where a 16.4 database had experienced some forced vacuuming due to potential wraparound, and a few days later a vacuum full failed with:
ERROR: found xmin 29,200,398 from before relfrozenxid 284,832,753
(commas are mine :)
Here's the curious part: Both CREATE TABLE AS SELECT and VACUUM FREEZE were able to run without any problems at all. Nothing else was active on this cluster (application was shut down to diagnose this). I used heap_force_freeze to 'fix' the row in question, which made vacfull happy for that row, but revealed another row right next to it with the same issue. Examining the row's t_infomask confirmed the row was, indeed, marked as frozen. Checked another handful of similar rows. All had unique xmins (i.e. one xmin = one ctid) and xmax always 0, plus sequential primary key vals, so looked like straightforward inserts. Server has not failed over, to my knowledge.
So why is vacfull bothering with these rows? What is different about vacfull vs vacfreeze for this check?
Cheers,
Greg
