Re: tuptoaster.c must *not* use SnapshotAny

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(at)spardat(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026