From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Greg Stark <stark(at)mit(dot)edu> |
Cc: | 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-20 17:54:34 |
Message-ID: | 20140220175434.GU28858@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2014-02-20 13:25:35 +0000, Greg Stark wrote:
> I have a database where a a couple rows don't appear in index scans
> but do appear in sequential scans. It looks like the same problem as
> Peter reported but this is a different database. I've extracted all
> the xlogdump records and below are the ones I think are relevant. You
> can see that lp 2 gets a few HOT updates and concurrently has someone
> create a MultiXact NO KEY UPDATE lock while one of those HOT updates
> is pending but not committed. The net result seems to be that the ctid
> update chain got broken. The index of course points to the head of the
> HOT chain so it doesn't find the live tail whereas the sequential scan
> picks it up.
>
> I don't see any evidence of MultiXactId wraparound, the members run to
> 001F and the offsets run to 000B. This is on a standby that's been
> activated but afaik that shouldn't change these files any more right?
I think this might actually be
c6cd27e36b9c58ceda8582ba81e37b6f9ad87d59,
2dcc48c35af5305fba0d8cb5e31fa0c25f52d13f might also be involved.
Hard to say at my current tiredness/caffeination level.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2014-02-20 23:42:12 | Re: Draft release notes up for review |
Previous Message | Alvaro Herrera | 2014-02-20 17:07:39 | Re: WAL Rate Limiting |