Re: tuptoaster.c must *not* use SnapshotAny - Mailing list pgsql-hackers

From Jan Wieck
Subject Re: tuptoaster.c must *not* use SnapshotAny
Date
Msg-id 200201171811.g0HIBO403651@saturn.janwieck.net
Whole thread Raw
In response to Re: tuptoaster.c must *not* use SnapshotAny  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: tuptoaster.c must *not* use SnapshotAny  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> "Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:
> >> It doesn't matter whether it's FrozenXid or not.  The tuple is not
> >> visible if it's got the wrong setting of HEAP_MOVED_OFF/IN.
>
> > But the FrozenXid tuple has HEAP_MOVED_IN and the original has
> > not yet been altered to HEAP_MOVED_OFF because of abort.
> > Is the HEAP_MOVED_IN tuple not visible ?
>
> Right.  Actually it doesn't matter whether the old tuple has
> HEAP_MOVED_OFF or not; it's still visible *until* the VACUUM commits.
> The commit atomically switches us from the state where the unmoved
> tuples are good to the state where the moved ones are good.
>
> This is all exactly the same whether FrozenXid is involved or not.
   Originally I added SnapshotAny only to solve the problem that   the lookup of the toast table happens  independant
from the   access  to  the  main  tuple, and that in fact the main tuple   could have been deleted by the own
transactionin between.
 
   Would changing SnapshotAny  to  honor  HEAP_MOVED_*  fix  the   problem?  If nothing else by now uses this snapshot,
itcould   be done in place.
 


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Bug in pg_dump/restore -o
Next
From: Brent Verner
Date:
Subject: Re: Bug in pg_dump/restore -o