Re: pg_upgrade and frozen xids

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: bricklen <bricklen(at)gmail(dot)com>, Natalie Wenz <nataliewenz(at)ebureau(dot)com>, pgsql-admin <pgsql-admin(at)postgresql(dot)org>
Subject: Re: pg_upgrade and frozen xids
Date: 2018-03-07 20:01:36
Message-ID: CAH2-Wz=aNHWcZ3HMgofmvMDcUeLG9TVei1_ZCVNqROJAsapxYQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

On Wed, Mar 7, 2018 at 11:48 AM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)com> wrote:
> I wonder if this may be related to changes in collation algorithm. If
> the indexes are all on text columns, I think you would be better served
> by reindexing them all instead of trying to treat this situation as a
> code bug.

I happen to know that bricklen already ran amcheck. There were errors,
but they were not consistent with a collation issue. Rather, it looked
like something was up with the storage layer -- the sibling links of a
pair of pages were not in mutual agreement.

Even if that wasn't something that I knew already, I still would not
suspect opclass misbehavior of any variety. VACUUM doesn't care about
the ordering of items on the page in the case of nbtree. And, it
performs a physical order scan there (albeit with some extra trickery
to prevent races due to concurrent splits). Index tuples that could
end up being unreachable to index scans due to opclass misbehavior
should remain reachable to VACUUM.

--
Peter Geoghegan

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Peter Geoghegan 2018-03-07 20:11:15 Re: pg_upgrade and frozen xids
Previous Message Alvaro Herrera 2018-03-07 19:48:11 Re: pg_upgrade and frozen xids