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

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Greg Stark <stark(at)mit(dot)edu>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Peter Geoghegan <pg(at)heroku(dot)com>
Subject: Re: Another possible corruption bug in 9.3.2 or possibly a known MultiXact problem?
Date: 2014-02-24 21:31:03
Message-ID: 20140224213103.GN6718@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-02-24 22:06:53 Re: Changeset Extraction v7.7
Previous Message Andres Freund 2014-02-24 21:17:31 Re: Another possible corruption bug in 9.3.2 or possibly a known MultiXact problem?