Re: Another possible corruption bug in 9.3.2 or possibly a known MultiXact problem?
От | Andres Freund |
---|---|
Тема | Re: Another possible corruption bug in 9.3.2 or possibly a known MultiXact problem? |
Дата | |
Msg-id | 20140224213103.GN6718@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: Another possible corruption bug in 9.3.2 or possibly a known MultiXact problem? (Andres Freund <andres@2ndquadrant.com>) |
Список | pgsql-hackers |
On 2014-02-24 22:17:31 +0100, Andres Freund wrote: > Those together explain the story. Note this bit: > > 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; > ... > } > > So, the replay of FD/2F0AE4D0 breaks the ctid chain *and* unsets the > HOT_UPDATED flag. Some quick archeology shows that the HeapTupleHeaderClearHotUpdated() was in the original HOT commit (282d2a03d) and clearing of t_ctid was in the original commit implementing FOR SHARE (bedb78d38). Both look like they are copied from other places, I don't immediately see any need for them here... Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: