Re: Another possible corruption bug in 9.3.2 or possibly a known MultiXact problem?

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: Another possible corruption bug in 9.3.2 or possibly a known MultiXact problem?
Дата
Msg-id 20140227143436.GN4759@eldon.alvh.no-ip.org
обсуждение исходный текст
Ответ на Re: Another possible corruption bug in 9.3.2 or possibly a known MultiXact problem?  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: Another possible corruption bug in 9.3.2 or possibly a known MultiXact problem?  (Greg Stark <stark@mit.edu>)
Список pgsql-hackers
Andres Freund wrote:
> On 2014-02-26 18:18:05 -0300, Alvaro Herrera wrote:
> > Andres Freund wrote:
> > 
> > > static void
> > > heap_xlog_lock(XLogRecPtr lsn, XLogRecord *record)
> > > {
> > > ...
> > >     HeapTupleHeaderClearHotUpdated(htup);
> > >     HeapTupleHeaderSetXmax(htup, xlrec->locking_xid);
> > >     HeapTupleHeaderSetCmax(htup, FirstCommandId, false);
> > >     /* Make sure there is no forward chain link in t_ctid */
> > >     htup->t_ctid = xlrec->target.tid;
> > > ...
> > > }
> > 
> > I think the fix is to reset HOT_UPDATED and t_ctid only if the infomask
> > says the tuple is LOCKED_ONLY, per the attached patch.
> 
> Looks good to me.

Thanks, pushed.

Greg, Peter, if you could update your standbys to the current HEAD of
REL9_3_STABLE for the affected apps and verify the problem no longer
shows up in a reasonable timeframe, it would be great.  (I'm assuming
you saw this happen repeatedly.)

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services



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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Unfortunate choice of short switch name in pgbench
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Unfortunate choice of short switch name in pgbench