Re: pg_upgrade and statistics
Andrew Dunstan <andrew@dunslane.net>
From: Andrew Dunstan <andrew@dunslane.net>
To: Bruce Momjian <bruce@momjian.us>
Cc: Peter Eisentraut <peter_e@gmx.net>, Tom Lane <tgl@sss.pgh.pa.us>, Kevin Grittner <Kevin.Grittner@wicourts.gov>, Daniel Farina <daniel@heroku.com>, Greg Stark <stark@mit.edu>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2012-03-15T15:15:42Z
Lists: pgsql-hackers
On 03/15/2012 11:03 AM, Bruce Momjian wrote: > On Thu, Mar 15, 2012 at 08:22:24AM +0200, Peter Eisentraut wrote: >> On ons, 2012-03-14 at 17:36 -0400, Bruce Momjian wrote: >>> Well, I have not had to make major adjustments to pg_upgrade since 9.0, >>> meaning the code is almost complete unchanged and does not require >>> additional testing for each major release. If we go down the road of >>> dumping stats, we will need to adjust for stats changes and test this to >>> make sure we have made the proper adjustment for every major release. >> I think this could be budgeted under keeping pg_dump backward >> compatible. You have to do that anyway for each catalog change, and so >> doing something extra for a pg_statistic change should be too shocking. > Well, the big question is whether the community wants to buy into that > workload. It isn't going to be possible for me to adjust the statistics > dump/restore code based on the changes someone makes unless I can fully > understand the changes by looking at the patch. You're not the only person who could do that. I don't think this is all down to you. It should just be understood that if the stats format is changed, adjusting pg_upgrade needs to be part of the change. When we modified how enums worked, we adjusted pg_upgrade at the same time. That sort of thing seems totally reasonable to me. I haven't looked at it, but I'm wondering how hard it is going to be in practice? cheers andrew