Re: tuptoaster.c must *not* use SnapshotAny

Tom Lane wrote:
> Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> writes:
> > The same snapshot for both the main and the toast table
> > seems better though I don't know how it's difficult to
> > change.
>
> That would be cleaner but I don't see any way to do it. The toasted
> value gets passed all over the system, potentially, before someone asks
> to detoast it. At that point you really don't have a good way to know
> which snapshot was used to fetch the main-table row.

That's IMHO not the point. The design of toast is that if a
main heap tuple points to a toast id, and the heap tuple at
scan time was visible, then no matter what, the value is
readable. Regardless of any isolation level or command
counter or whatnot. That's achieved by allways assigning a
new toast ID on change of a toasted value. So if the columns
value changed, the old and new rows point to different toast
values not by visibility but by toast id. If it did not
change, they point to the same.

The problem arises only because SnapshotAny is *too* blind
and ignores the special vacuum HEAP_MOVED_* states, so that a
scan after a crashed vacuum full, that left yet unborn moved-
in tuples in the toast table, can see them.

Since the design of toast is NO NEED to care about snapshots
during toast value fetching, I don't see why doing so now
would be a cleaner solution.

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