Re: PgUpgrade bumped my XIDs by ~50M?

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Jerry Sievers <gsievers19(at)comcast(dot)net>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: PgUpgrade bumped my XIDs by ~50M?
Date: 2018-04-05 20:39:11
Message-ID: 20180405203911.GA22360@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, Apr 4, 2018 at 08:29:06PM -0400, Bruce Momjian wrote:
> On Wed, Apr 4, 2018 at 07:13:36PM -0500, Jerry Sievers wrote:
> > Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > > Is it possible that pg_upgrade used 50M xids while upgrading?
> >
> > Hi Bruce.
> >
> > Don't think so, as I did just snap the safety snap and ran another
> > upgrade on that.
> >
> > And I also compared txid_current for the upgraded snap and our running
> > production instance.
> >
> > The freshly upgraded snap is ~50M txids behind the prod instance.
>
> Are the objects 50M behind or is txid_current 50M different? Higher or
> lower?

Uh, here is a report of a similar problem from March 6, 2018:

https://www.postgresql.org/message-id/flat/C44C73BC-6B3A-42E0-9E44-6CE4E5B5D601%40ebureau(dot)com#C44C73BC-6B3A-42E0-9E44-6CE4E5B5D601(at)ebureau(dot)com

I upgraded a very large database from 9.6 to 10.1 via pg_upgrade
recently, and ever since, the auto vacuum has been busy on a large
legacy table that has experienced no changes since the upgrade. If the
whole table had been frozen prior to the upgrade, would you expect it to
stay frozen?

It sure smells like we have a bug here. Could this be statistics
collection instead?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Jerry Sievers 2018-04-05 21:02:16 Re: PgUpgrade bumped my XIDs by ~50M?
Previous Message Adam =?utf-8?Q?Sj=C3=B8gren?= 2018-04-05 20:27:04 Re: ERROR: unexpected chunk number 0 (expected 1) for toast value 76753264 in pg_toast_10920100