Re: heap_xlog_lock forgets to reset HEAP_XMAX_INVALID

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: heap_xlog_lock forgets to reset HEAP_XMAX_INVALID
Дата
Msg-id 20160715214704.fv2xsc7fzxtug3v5@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: heap_xlog_lock forgets to reset HEAP_XMAX_INVALID  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
On 2016-07-15 17:43:44 -0400, Alvaro Herrera wrote:
> Andres Freund wrote:
> > On 2016-07-15 17:23:57 -0400, Alvaro Herrera wrote:
> 
> > > Maybe we should change fix_infomask_from_infobits() to reset
> > > HEAP_XMAX_BITS | HEAP_MOVED too (and HEAP_KEYS_UPDATED I suppose), to
> > > avoid doing it in each callsite.
> > 
> > Yea, I was thinking of that as well. But there's code like
> >         htup->t_infomask &= ~(HEAP_XMAX_BITS | HEAP_MOVED);
> >         htup->t_infomask2 &= ~HEAP_KEYS_UPDATED;
> >         if (hot_update)
> >             HeapTupleHeaderSetHotUpdated(htup);
> >         else
> >             HeapTupleHeaderClearHotUpdated(htup);
> >         fix_infomask_from_infobits(xlrec->old_infobits_set, &htup->t_infomask,
> >                                    &htup->t_infomask2);
> > 
> > so I'd rather only clean this up in master.

Well, I think we should move setting hot updated into infomask as well,
then rename fix_infomask_from_infobits to set_infomask_from_infobits and
such. I want to get this fix and the heap_update stuff in now, before
the beta, with time to fix potential fallout. So it's the minimal fix,
if I do it...

Andres



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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: heap_xlog_lock forgets to reset HEAP_XMAX_INVALID
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Version number for pg_control