Re: pg_regress cleans up tablespace twice.
От | Michael Paquier |
---|---|
Тема | Re: pg_regress cleans up tablespace twice. |
Дата | |
Msg-id | 20200617070804.GC2361@paquier.xyz обсуждение исходный текст |
Ответ на | Re: pg_regress cleans up tablespace twice. (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Ответы |
Re: pg_regress cleans up tablespace twice.
|
Список | pgsql-hackers |
On Fri, May 15, 2020 at 05:25:08PM +0900, Kyotaro Horiguchi wrote: > I thought of that but didn't in the patch. I refrained from doing > that because the output directory is dedicatedly created at the only > place (pg_upgrade test) where the --outputdir is specified. (I think I > tend to do too-much.) So, I have reviewed the patch aimed at removing the cleanup of testtablespace done with WIN32, and finished with the attached to clean up things. I simplified the logic, to not have to parse REGRESS_OPTS for --outputdir (no need for a regex, leaving EXTRA_REGRESS_OPTS alone), and reworked the code so as the tablespace cleanup only happens only where we need to: check, installcheck and upgradecheck. No need for that with contribcheck, modulescheck, plcheck and ecpgcheck. Note that after I changed my patch, this converged with a portion of patch 0002 you have posted here: https://www.postgresql.org/message-id/20200511.171354.514381788845037011.horikyota.ntt@gmail.com Now about 0002, I tend to agree that we should try to do something about pg_upgrade test creating removing and then creating an extra testtablespace path that is not necessary as pg_upgrade test uses its own --outputdir. I have not actually seen this stuff being a problem in practice as the main regression test suite runs first, largely before pg_upgrade test even with parallel runs so they have a low probability of conflict. I'll try to think about a couple of options, one of them I have in mind now being that we could finally switch the upgrade tests to TAP and let test.sh go to the void. This is an independent problem, so let's tackle both issues separately. -- Michael
Вложения
В списке pgsql-hackers по дате отправления: