From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> |
Cc: | Daniel Gustafsson <daniel(at)yesql(dot)se>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter(at)eisentraut(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Subject: | Re: Test to dump and restore objects left behind by regression |
Date: | 2025-02-11 23:55:14 |
Message-ID: | Z6vjYutzuh8-xNWL@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Feb 11, 2025 at 12:19:33PM +0530, Ashutosh Bapat wrote:
> Sorry for replying late here. The refactored code in
> 002_compare_backups.pl has a potential to cause confusion even without
> this refactoring. The differences in tablespace paths are adjusted in
> compare_files() and not in the actual dump outputs. In case there's a
> difference other than paths, diff between the dump outputs is reported
> which will also show the differences in paths. That might mislead
> developers in thinking that the differences in paths are also not
> expected. Am I right?
Logically, 002_compare_backups.pl is still the same, isn't it? We're
still passing the file paths to compare_text(), except that the
comparison routine is given as an argument one level higher.
You are right that there could be an argument for changing the files
are they are on-disk, and do a diff based on what's on disk after what
has changed so as the filtered parts are out of the report. However,
there is also an argument for not changing them as that's more useful
to know the original state of the dump for debugging. This one
involves only a small change, which is OK as-is, IMHO.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2025-02-11 23:56:04 | Re: pg_rewind with --write-recovery-conf option doesn't write dbname to primary_conninfo value. |
Previous Message | Michail Nikolaev | 2025-02-11 23:39:09 | Re: [BUG?] check_exclusion_or_unique_constraint false negative |