
> You're right, lazy VACUUM doesn't create this issue.  My mistake.
> But VACUUM FULL does.
> 
> > I can only see a problem with a partway through vacuum 
> full, that aborted.
> 
> Exactly.

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 ?

How do we know, that a (newly) FrozenXid tuple does not still have 
a (visible) duplicate ?

Andreas

Wed, 16 Jan 2002 18:40:25 +0100
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>
Re: tuptoaster.c must *not* use SnapshotAny 
"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

Wed, 16 Jan 2002 13:06:01 -0500
Tom Lane <tgl@sss.pgh.pa.us>
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@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, Pennsylvania 19026

Wed, 16 Jan 2002 18:10:06 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: tuptoaster.c must *not* use SnapshotAny