Re: Test to dump and restore objects left behind by regression - Mailing list pgsql-hackers
From | vignesh C |
---|---|
Subject | Re: Test to dump and restore objects left behind by regression |
Date | |
Msg-id | CALDaNm1zcLL514UaZ+Jxa0O9rLDzUAYf1nS3h0htKW9PwpfaLA@mail.gmail.com Whole thread Raw |
In response to | Re: Test to dump and restore objects left behind by regression (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>) |
Responses |
Re: Test to dump and restore objects left behind by regression
Re: Test to dump and restore objects left behind by regression |
List | pgsql-hackers |
On Wed, 19 Mar 2025 at 17:13, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> wrote: > > On Thu, Mar 13, 2025 at 6:10 PM Ashutosh Bapat > <ashutosh.bapat.oss@gmail.com> wrote: > > > > > > I think the fix is to explicitly pass --lc-monetary to the old cluster > > > and the restored cluster. 003 patch in the attached patch set does > > > that. Please check if it fixes the issue for you. > > > > > > Additionally we should check that it gets copied to the new cluster as > > > well. But I haven't figured out how to get those settings yet. This > > > treatment is similar to how --lc-collate and --lc-ctype are treated. I > > > am wondering whether we should explicitly pass --lc-messages, > > > --lc-time and --lc-numeric as well. > > > > > > 2d819a08a1cbc11364e36f816b02e33e8dcc030b introduced buildin locale > > > provider and added overrides to LC_COLLATE and LC_TYPE. But it did not > > > override other LC_, which I think it should have. In pure upgrade > > > test, the upgraded node inherits the locale settings of the original > > > cluster, so this wasn't apparent. But with pg_dump testing, the > > > original and restored databases are independent. Hence I think we have > > > to override all LC_* settings by explicitly mentioning --lc-* options > > > to initdb. Please let me know what you think about this? > > > > > Investigated this further. The problem is that the pg_regress run > creates regression database with specific properties but the restored > database does not have those properties. That led me to a better > solution. Additionally it's local to the new test. Use --create when > dumping and restoring the regression database. This way the database > properties or "configuration variable settings (as pg_dump > documentation calls them) are copied to the restored database as well. > Those properties include LC_MONETARY. Additionally now the test covers > --create option as well. > > PFA patches. Will it help the execution time if we use --jobs in case of pg_dump and pg_restore wherever supported: + $src_node->command_ok( + [ + 'pg_dump', "-F$format", '--no-sync', + '-d', $src_node->connstr('regression'), + '--create', '-f', $dump_file + ], + "pg_dump on source instance in $format format"); + + my @restore_command; + if ($format eq 'plain') + { + # Restore dump in "plain" format using `psql`. + @restore_command = [ 'psql', '-d', 'postgres', '-f', $dump_file ]; + } + else + { + @restore_command = [ + 'pg_restore', '--create', + '-d', 'postgres', $dump_file + ]; + } Should the copyright be only 2025 in this case: diff --git a/src/test/perl/PostgreSQL/Test/AdjustDump.pm b/src/test/perl/PostgreSQL/Test/AdjustDump.pm new file mode 100644 index 00000000000..74b9a60cf34 --- /dev/null +++ b/src/test/perl/PostgreSQL/Test/AdjustDump.pm @@ -0,0 +1,167 @@ + +# Copyright (c) 2024-2025, PostgreSQL Global Development Group Regards, Vignesh
pgsql-hackers by date: