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:

Previous
From: "Matthew T. O'Connor"
Date:
Subject: question with beta5
Next
From: Tom Lane
Date:
Subject: Re: question with beta5