Tom Lane wrote:
> Hiroshi Inoue <Inoue@tpf.co.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
bytoast 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,
sothat 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
doingso 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@Yahoo.com #
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
