Thread: [PATCH] Backport perl tests for pg_upgrade from 322becb60
Hello! In previous discussion (https://www.postgresql.org/message-id/flat/6b05291c-f252-4fae-317d-b50dba69c311%40inbox.ru) On 05.07.2022 22:08, Justin Pryzby wrote: > I'm not > sure if anyone is interested in patching test.sh in backbranches. I'm not > sure, but there may be more interest to backpatch the conversion to TAP > (322becb60). > As far as i understand from this thread: https://www.postgresql.org/message-id/flat/Yox1ME99GhAemMq1%40paquier.xyz, the aim of the perl version for the pg_upgrade tests is to achieve equality of dumps for most cross-versions cases. If so this is the significant improvement as previously in test.sh resulted dumps retained unequal and the user was asked to eyeball them manually during cross upgrades between different major versions. So, the backport of the perl tests also seems preferable to me. In the attached patch has a backport to REL_13_STABLE. It has been tested from 9.2+ and give zero dumps diff from 10+. Also i've backported b34ca595, ba15f161, 95c3a195, 4c4eaf3d and b3983888 to reduce changes in the 002_pg_upgrade.pl and b33259e2 to fix an error when upgrading from 9.6. Dumps filtering and some other changes were backported from thread https://www.postgresql.org/message-id/flat/Yox1ME99GhAemMq1%40paquier.xyz too. Would be very grateful for comments and suggestions before trying to do this for other versions. I have a some question concerning patch tester. As Justin said it fails on non-master patches > since it tries to apply all the *.patch files to the master branch, one after > another. For branches other than master, I suggest to name the patches *.txt > or similar. So, i made a .txt extension for patch, but i would really like to set a patch tester on it. Is there any way to do this? With best regards, -- Anton A. Melnikov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
Attachment
Add backport to REL_14_STABLE. Unlike to the 13th version's one there are still some differences in the final dumps, eg during upgrade test 12->14. The similar differences present during upgrade test 12->master. Achieving zero dump diffs needs additional work, now in progress. With best regards, -- Anton A. Melnikov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
Attachment
On Mon, Aug 01, 2022 at 01:02:21AM +0300, Anton A. Melnikov wrote: > As far as i understand from this thread: https://www.postgresql.org/message-id/flat/Yox1ME99GhAemMq1%40paquier.xyz, > the aim of the perl version for the pg_upgrade tests is to achieve equality of dumps for most cross-versions cases. > If so this is the significant improvement as previously in test.sh resulted dumps retained unequal and the user > was asked to eyeball them manually during cross upgrades between different major versions. > So, the backport of the perl tests also seems preferable to me. I don't really agree with that. These TAP tests are really new development, and it took a few tries to get them completely right (well, as much right as it holds for HEAD). If we were to backport any of this, there is a risk of introducing a bug in what we do with any of that, potentially hiding a issue critical related to pg_upgrade. That's not worth taking a risk for. Saying that, I agree that more needs to be done, but I would limit that only to HEAD and let it mature more into the tree in an incremental fashion. -- Michael
Attachment
Hello! On 09.12.2022 08:19, Michael Paquier wrote: > On Mon, Aug 01, 2022 at 01:02:21AM +0300, Anton A. Melnikov wrote: >> As far as i understand from this thread: https://www.postgresql.org/message-id/flat/Yox1ME99GhAemMq1%40paquier.xyz, >> the aim of the perl version for the pg_upgrade tests is to achieve equality of dumps for most cross-versions cases. >> If so this is the significant improvement as previously in test.sh resulted dumps retained unequal and the user >> was asked to eyeball them manually during cross upgrades between different major versions. >> So, the backport of the perl tests also seems preferable to me. > > I don't really agree with that. These TAP tests are really new > development, and it took a few tries to get them completely right > (well, as much right as it holds for HEAD). If we were to backport > any of this, there is a risk of introducing a bug in what we do with > any of that, potentially hiding a issue critical related to > pg_upgrade. That's not worth taking a risk for. > > Saying that, I agree that more needs to be done, but I would limit > that only to HEAD and let it mature more into the tree in an > incremental fashion. > -- I have withdrawn the patch with the backport, but then the question is whether we will make fixes in older test.sh tests seems to be remains open. Will we fix it? Justin is not sure if anyone needs this: https://www.postgresql.org/message-id/67b6b447-e9cb-ebde-4a6b-127aea7ca268%40inbox.ru Also found that the test from older versions fails in the current master. Proposed a fix in a new thread: https://www.postgresql.org/message-id/49f389ba-95ce-8a9b-09ae-f60650c0e7c7%40inbox.ru Would be glad to any remarks. With the best wishes, -- Anton A. Melnikov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
On Mon, Dec 19, 2022 at 04:16:53AM +0300, Anton A. Melnikov wrote: > I have withdrawn the patch with the backport, but then the question is whether we > will make fixes in older test.sh tests seems to be remains open. > Will we fix it? Justin is not sure if anyone needs this: > https://www.postgresql.org/message-id/67b6b447-e9cb-ebde-4a6b-127aea7ca268%40inbox.ru This introduces an extra maintenance cost over the existing things in the stable branches. > Also found that the test from older versions fails in the current master. > Proposed a fix in a new thread: https://www.postgresql.org/message-id/49f389ba-95ce-8a9b-09ae-f60650c0e7c7%40inbox.ru Thanks. Yes, this is the change of aclitem from 32b to 64b, which is something that needs some tweaks. So let's fix this one. -- Michael