Re: tuptoaster.c must *not* use SnapshotAny - Mailing list pgsql-hackers
From | Bruce Momjian |
---|---|
Subject | Re: tuptoaster.c must *not* use SnapshotAny |
Date | |
Msg-id | 200201162310.g0GNA6M10530@candle.pha.pa.us Whole thread Raw |
In response to | Re: tuptoaster.c must *not* use SnapshotAny (Tom Lane <tgl@sss.pgh.pa.us>) |
List | pgsql-hackers |
I have added more comments to tqual.c to the stuff Tom just added. I added visibility items to the top of each function comment. --------------------------------------------------------------------------- Tom Lane wrote: > "Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes: > > Can you try give me a hint, why an aborted VACUUM FULL will not allways be > > a problem (also for other operations) until you run another VACUUM FULL > > that succeeds ? > > Because noplace else uses SnapshotAny, basically. The only really > legitimate use I can see for it is in Tatsuo's contrib/pgstattuple > hack: that wants to count both visible and invisible tuples. > > > How do we know, that a (newly) FrozenXid tuple does not still have > > a (visible) duplicate ? > > It's *not* visible, if you are applying any visibility checks whatever. > But SnapshotAny bypasses all visibility checking. > > I forgot to answer your question about what these mean. See > src/backend/utils/time/tqual.c for the gory details, but if you > are willing to accept the summary comments in that file: > > Any No visibility check whatever > > Self Other committed xacts + effects of this xact up to > *and including* current command > > Now Other committed xacts + effects of this xact up to > *but not including* current command > > Dirty like Self, but can see effects of other in-progress > xacts too > > Snapshot like Now, but specified other xacts are considered > uncommitted even if they've actually committed by now > > There are also special visibility rules for Update and Vacuum, which > are not really different from the normal rules, they just return more > information than "visible" or "not visible". (Dirty returns some > side information too.) > > Hmm. Now that I look at it, Self probably isn't quite right either; > if we are reading a main-table tuple that's committed dead but is > still visible according to our snapshot, we need to be able to see > its toast tuples too; but they're committed dead as well. Sigh. > I think we need a special visibility rule for TOAST, that only > checks for HEAP_MOVED_IN/HEAP_MOVED_OFF (the bits that take care > of VACUUM moves). > > Comments? > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
pgsql-hackers by date: