From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Zeugswetter Andreas SB SD <ZeugswetterA(at)spardat(dot)at>, Jan Wieck <JanWieck(at)Yahoo(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: tuptoaster.c must *not* use SnapshotAny |
Date: | 2002-01-16 23:10:06 |
Message-ID: | 200201162310.g0GNA6M10530@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(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
From | Date | Subject | |
---|---|---|---|
Next Message | Yasuo Ohgaki | 2002-01-17 00:46:17 | Re: Ignore this one ... |
Previous Message | Tom Lane | 2002-01-16 23:03:59 | Re: question with beta5 |