Re: problems with table corruption continued

Поиск
Список
Период
Сортировка
От Mikheev, Vadim
Тема Re: problems with table corruption continued
Дата
Msg-id 3705826352029646A3E91C53F7189E32518451@sectorbase2.sectorbase.com
обсуждение исходный текст
Ответ на problems with table corruption continued  ("Brian Hirt" <bhirt@mobygames.com>)
Ответы Re: problems with table corruption continued  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> This is trying to get rid of the original copy of a tuple that's been
> moved to another page.  The problem is that your index 
> function causes a
> table scan, which means that by the time control gets here, 
> someone else
> has looked at this tuple and marked it good --- so the initial test of
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> HEAP_XMIN_COMMITTED fails, and the tuple is never removed!
> 
> I would say that it's incorrect for vacuum.c to assume that
> HEAP_XMIN_COMMITTED can't become set on HEAP_MOVED_OFF/HEAP_MOVED_IN
> tuples during the course of vacuum's processing; after all, the xmin
> definitely does refer to a committed xact, and we can't realistically
> assume that we know what processing will be induced by user-defined
> index functions.  Vadim, what do you think?  How should we fix this?

But it's incorrect for table scan to mark tuple as good neither.
Looks like we have to add checks for the case
TransactionIdIsCurrentTransactionId(tuple->t_cmin) when
there is HEAP_MOVED_OFF or HEAP_MOVED_IN in t_infomask to
all HeapTupleSatisfies* in tqual.c as we do in
HeapTupleSatisfiesDirty - note comments about uniq btree-s there.

Vadim


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Mike Mascari
Дата:
Сообщение: Re: Concerns about this release
Следующее
От: Tom Lane
Дата:
Сообщение: Re: problems with table corruption continued