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