On Tue, Apr 12, 2022 at 2:53 PM Peter Geoghegan <p...@bowt.ie> wrote:
> Recent work on VACUUM and relfrozenxid advancement required that I > update the maintenance.sgml VACUUM documentation ("Routine > Vacuuming"). It was tricky to keep things current, due in part to > certain structural problems. Many of these problems are artifacts of > how the document evolved over time. > > "Routine Vacuuming" ought to work as a high level description of how > VACUUM keeps the system going over time. The intended audience is > primarily DBAs, so low level implementation details should either be > given much less prominence, or not even mentioned. We should keep it > practical -- without going too far in the direction of assuming that > we know the limits of what information might be useful. > +1 I've attached some off-the-cuff thoughts on reworking the first three paragraphs and the note. It's hopefully useful for providing perspective if nothing else. > My high level concerns are: > > * Instead of discussing FrozenTransactionId (and then explaining how > that particular magic value is not really used anymore anyway), why > not describe freezing in terms of the high level rules? > Agreed and considered > > Something along the lines of the following seems more useful: "A tuple > whose xmin is frozen (and xmax is unset) is considered visible to > every possible MVCC snapshot. In other words, the transaction that > inserted the tuple is treated as if it ran and committed at some point > that is now *infinitely* far in the past." > I'm assuming and caring only about visible rows when I'm reading this section. Maybe we need to make that explicit - only xmin matters (and the invisible frozen flag)? > It might also be useful to describe freezing all of a live tuple's > XIDs as roughly the opposite process as completely physically removing > a dead tuple. It follows that we don't necessarily need to freeze > anything to advance relfrozenxid (especially not on Postgres 15). > I failed to pickup on how this and "mod-2^32" math interplay, and I'm not sure I care when reading this. It made more sense to consider "shortest path" along the "circle". > Currently, "25.1.5. Preventing Transaction ID Wraparound Failures" > says this, right up-front: > > "But since transaction IDs have limited size (32 bits) a cluster that > runs for a long time (more than 4 billion transactions) would suffer > transaction ID wraparound" > I both agree and disagree - where I settled (as of now) is reflected in the patch. > * The description of wraparound sounds terrifying, implying that data > corruption can result. > Agreed, though I just skimmed a bit after the material the patch covers. > > * XID space isn't really a precious resource -- it isn't even a > resource at all IMV. > Agreed > > * We don't cleanly separate discussion of anti-wraparound autovacuums, > and aggressive vacuums, and the general danger of wraparound (by which > I actually mean the danger of having the xidStopLimit stop limit kick > in). > Didn't really get this far. I am wondering, for the more technical details, is there an existing place to send xrefs, do you plan to create one, or is it likely unnecessary? David J.
v0001-doc-reworking-of-vacuum-transaction-wraparound-section.patch
Description: Binary data