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
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 |