Re: tuptoaster.c must *not* use SnapshotAny

Поиск
Список
Период
Сортировка
Искать
От
Zeugswetter Andreas SB SD
Тема
Re: tuptoaster.c must *not* use SnapshotAny
Дата
Msg-id
46C15C39FEB2C44BA555E356FBCD6FA41EB4B7@m0114.s-mxs.net
Список
Дерево обсуждения
tuptoaster.c must *not* use SnapshotAny Tom Lane <tgl@sss.pgh.pa.us>
Re: tuptoaster.c must *not* use SnapshotAny Jan Wieck <janwieck@yahoo.com>
Re: tuptoaster.c must *not* use SnapshotAny Tom Lane <tgl@sss.pgh.pa.us>
Re: tuptoaster.c must *not* use SnapshotAny "Command Prompt, Inc." <pgsql-hackers@commandprompt.com>
Re: tuptoaster.c must *not* use SnapshotAny Tom Lane <tgl@sss.pgh.pa.us>

> > 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 am concerned about the case where VACUUM FULL:
1. inserts heap tuple to new location using FrozenXid
2. updates original heap tuples's xmax

What if we crash/abort between step 1 and 2 but we used FrozenXid for 1.
Don't know if we actually do this, but imho we are only allowed 
to use FrozenXid for an inplace vacuum operation.

Andreas

В списке pgsql-hackers по дате отправления
От: Marc G. Fournier
Дата:
Сообщение: Re: RC1 date?
От: Daniel Kalchev
Дата:
Сообщение: Re: RC1 date?
FAQ