Re: tuptoaster.c must *not* use SnapshotAny

From: Jan Wieck <janwieck(at)yahoo(dot)com>
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-17 18:11:24
Message-ID: 200201171811.g0HIBO403651@saturn.janwieck.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)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 transaction in between.

Would changing SnapshotAny to honor HEAP_MOVED_* fix the
problem? If nothing else by now uses this snapshot, it could
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(at)Yahoo(dot)com #

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Brent Verner 2002-01-17 18:25:30 Re: Bug in pg_dump/restore -o
Previous Message Bruce Momjian 2002-01-17 17:49:29 Bug in pg_dump/restore -o