Re: Test to dump and restore objects left behind by regression

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