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 по дате отправления: