Re: Test to dump and restore objects left behind by regression - Mailing list pgsql-hackers

On Thu, Mar 20, 2025 at 8:37 PM vignesh C <vignesh21@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