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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
