Re: statistics import and export: another difference in dump/restore
От | Ashutosh Bapat |
---|---|
Тема | Re: statistics import and export: another difference in dump/restore |
Дата | |
Msg-id | CAExHW5uQmFfY0G+hwDboE9MA4F6Qretau4aoqq2yo+ErMXhBtQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: statistics import and export: another difference in dump/restore (Jeff Davis <pgsql@j-davis.com>) |
Список | pgsql-hackers |
On Wed, Apr 2, 2025 at 10:55 PM Jeff Davis <pgsql@j-davis.com> wrote: > > On Wed, 2025-04-02 at 15:35 +0530, Ashutosh Bapat wrote: > > Once we fix this issue, we need to enable statistics dump and > > comparison in pg_upgrade/002_pg_upgrade using the attached patch. > > The diff appears to be an issue in 002_pg_upgrade.pl introduced in > 172259afb5. There are two dumps taken from $oldnode: $src_dump is taken > on line 321, and then $dump_file is taken on line 339. $dump_file is > used for the restore, but then $src_dump is used for the comparison. > > If autovacuum were off, then $src_dump and $dump_file should be the > same, but autovacuum is not disabled until line 415. Furthermore, > there's an initdb between lines 321 and 339, allowing autovacuum enough > time to activate. Otherwise we probably wouldn't have noticed. Thanks for the analysis. This is useful. I will post a fix on the original thread. I have assigned myself and fixed the open item entry. > > You could disable autovacuum earlier; though not too early, because > allowing it time to run improves test coverage for stats. Or, you could > use the same $src_dump for both restoration and comparison, but it > looks like you wanted coverage of the --create option. (Aside: why > parallel restore there? Is that just for test coverage or was there a > performance reason?) For performance. -- Best Wishes, Ashutosh Bapat
В списке pgsql-hackers по дате отправления: