Re: assertion failure 9.3.4

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Josh Berkus <josh(at)agliodbs(dot)com>
Subject: Re: assertion failure 9.3.4
Date: 2014-04-24 20:21:14
Message-ID: 20140424202114.GC25695@eldon.alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera wrote:
> Alvaro Herrera wrote:
>
> > I'm thinking about the comparison of full infomask as you propose
> > instead of just the bits that we actually care about. I think the only
> > thing that could cause a spurious failure (causing an extra execution of
> > the HeapTupleSatisfiesUpdate call and the stuff below) is somebody
> > setting HEAP_XMIN_COMMITTED concurrently; but that seems infrequent
> > enough that it should pretty harmless. However, should we worry about
> > possible future infomask bit changes that could negatively affect this
> > behavior?
>
> Here's a complete patch illustrating what I mean. This is slightly more
> expensive than straight infomask comparison in terms of machine
> instructions, but that seems okay to me.

I have pushed a slightly tweaked version of this, after verifying that
it solves the problem in Andrew's test environment.

Josh, if you could verify that it solves the problem for you too, it'd
be great.

Thanks for the report and test case.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2014-04-24 21:28:14 Re: slow startup due to LWLockAssign() spinlock
Previous Message Christopher Browne 2014-04-24 19:47:56 Re: UUIDs in core WAS: 9.4 Proposal: Initdb creates a single table