VACUUM details (vacuum_freeze_min_age/vacuum_freeze_table_age)

Hi all.

After reading the manual's (v9.2) Chapter 23 and in particular sections 23.1.5 i believe i've got some confusion with respect to VACUUM's details.

Assume we're at t0 and we just VACUUM'ed (simple, not FREEZE) a specific table and txid_current()=1500 and the pg_class entry for this table shows relfrozenxid=700.

Q: The 'relfrozenxid' is the freeze cutoff XID for this table which translates to: for this table all rows that show to have been modified by this XID, i.e.700, will always appear to be "in the past" to all normal transactions regardless of wraparound issues. Correct?

Docs: "vacuum_freeze_min_age controls how old an XID value has to be before it’s replaced with FrozenXID."
Q: So on a full table scan, a row's XID is updated to FrozenXID only if it's more than "vacuum_freeze_min_age" Xons old i.e. at least vacuum_freeze_min_age Xons have occured since this XID. Otherwise it's left at its current value. Correct?
Q: FrozenXID is the curren't VACUUM operation's XID?

Docs: "VACUUM normally skips pages that don’t have any dead row versions, but those pages might still have row
versions with old XID values. To ensure all old XIDs have been replaced by FrozenXID, a scan of
the whole table is needed. vacuum_freeze_table_age controls when VACUUM does that: a whole table
sweep is forced if the table hasn’t been fully scanned for vacuum_freeze_table_age minus
vacuum_freeze_min_age transactions."
Q: A full table scan with the intention of updating old row XIDs to FrozenXID is forced after (vacuum_freeze_table_age -
vacuum_freeze_min_age) Xons have occured since when? The last VACUUM or the last full table scan i.e. for example VACUUM FREEZE?
Q: In our example if e.g. vacuum_freeze_min_age=20000 and vacuum_freeze_table_age=50000 and no VACUUM occurs during 50000-20000=30000 Xons, then i'll get a forced full table scan where active row XIDs will be set to the new FrozenXID i.e. the current xid which is 31500 since I was at xid=1500 when i did the last VACUUM. But this will only affect the rows that are more than vacuum_freeze_min_age i.e. 20000 Xon's old. This means only rows with XID from 1500 to 11500. Is that anywhere near the truth?

Docs: "When VACUUM scans the whole table, after it’s finished age(relfrozenxid) should be a little more than the vacuum_freeze_min_age setting that was used (more by the number of transactions started since the VACUUM started)."
Q: At a non-production db I do:
# SHOW vacuum_freeze_min_age ;                                                                        
 vacuum_freeze_min_age
-----------------------
 50000000
(1 row)
# VACUUM FREEZE foo;
# SELECT relname,relfrozenxid,age(relfrozenxid) FROM pg_class WHERE relkind='r' and relname='foo';
 relname | relfrozenxid | age
---------+--------------+-----
 foo |         2880 |   0
(1 row)
I believe there is an error here. The age comes out 0 and not 50000000. Missing something or is it an error?

So, to conclude, VACUUM has 2 distinct tasks:
(i) to reclaim space by dead rows i.e. row versions that can no longer be seen by any active or future Xon and
(ii) avoid the wraparound issue by doing a full table scan which updates the row XIDs to FrozenXID before 2 billion Xons have passed. Correct?

Q: The first task updates the free space maps and happens when we do a simple VACUUM; this does not give the free space back to the OS (this is done only by VACUUM FULL). Correct?

Q: The second task, a full table scan, only happens when:
(i) we do a manual VACUUM FREEZE or
(ii) all pages of this table happen to have at least 1 dead row, thus will be examined by a simple VACUUM or
(iii) more than vacuum_freeze_table_age Xons have occured since the pg_class.relfrozenxid of this table
Correct?


TIA,
--thalis k.