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
2dcc48c35af5305fba0d8cb5e31fa0c25f52d13f might also be involved.

Hard to say at my current tiredness/caffeination level.


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:

Reply via email to