From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Andres Freund <andres(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-27 14:34:36 |
Message-ID: | 20140227143436.GN4759@eldon.alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-02-27 14:36:33 | Re: Unfortunate choice of short switch name in pgbench |
Previous Message | Alvaro Herrera | 2014-02-27 13:54:54 | Re: Unfortunate choice of short switch name in pgbench |