On Thu, Mar 20, 2025 at 8:37 PM vignesh C <vignes...@gmail.com> wrote: > > 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 > + ]; > + }
Will reply to this separately along with reply to Alvaro's comments. > > 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 The patch was posted in 2024 to this mailing list. So we better protect the copyright since then. I remember a hackers discussion where a senior member of the community mentioned that there's not harm in mentioning longer copyright periods than being stricter about it. I couldn't find the discussion though. -- Best Wishes, Ashutosh Bapat