3

When VACUUM starts, it will calculate a frozen transaction ID and freeze all tuples older than it. Will this frozen TXID be younger than the latest checkpoint?

If this is the case, then when the system crashes after VACUUM has deleted some dead tuples and the system recovers from this checkpoint, these tuples will be available to some transactions again during the replaying of WAL.

Is my understanding of this process correct?

1 Answer 1

1

It could well be that the freeze limit is younger than the latest checkpoint, if you set vacuum_freeze_min_age low enough, but that is no problem.

Tuples are either frozen (if they are all-visible and older than vacuum_freeze_min_age transactions) or removed (if they are "dead": invisible to everyone and no longer needed). Dead tuples are never frozen.

During crash recovery, all actions by VACUUM are replayed (with the possible exception of hint bits), so when recovery is done, all dead tuples are sure to be gone, and all frozen tuples will be frozen again.

Nobody can connect to the database before crash recovery is finished, so there is no danger of anybody seeing inconsistent data.

2
  • Thanks! So such a situation is possible (in chronological order): 1. checkpoint; 2. a transaction inserts tuple A; 3. a transaction uses A; 4. a transaction deletes A; 5. VACUUM removes the dead A from memory; 6. system crashes. Then in recovery, tuple A will be "revived", used, and finally removed again by replayed VACUUM. Is it correct? Jul 2, 2020 at 15:53
  • Yes, quite correct. Jul 2, 2020 at 16:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.