Bruce Momjian <bruce@momjian.us> writes:
> 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@momjian.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.com#C44C73BC-6B3A-42E0-9E44-6CE4E5B5D601@ebureau.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?
No clue but we still have the 9.5 safety snap that I can make repeated
sub-snaps of for mor testing.
I did one such test yesterday and things looked $normal after the
upgrade.
Noteworthy omission was that I did *not* run the post-analysis.
I could repeat the test more thoroughly.
We run a parallel analyzer framework to get huge DBs processed quickly.
And we generally do it in 2 passes; the first with def_stats_target
scaled down to finish quicker and hopefully be good enough to run
production. At this point we open the DB cluster for business.
Immediately following we again run the analyzer at full stats_target.
Any other suggestions what to also look at and I'll be glad to do and
report back.
Big Thanks!
--
Jerry Sievers
e: jerry.sievers@comcast.net
p: 312.241.7800