Re: pg_regress cleans up tablespace twice.

Поиск
Список
Период
Сортировка
От Kyotaro Horiguchi
Тема Re: pg_regress cleans up tablespace twice.
Дата
Msg-id 20200617.170231.2041463748911808790.horikyota.ntt@gmail.com
обсуждение исходный текст
Ответ на Re: pg_regress cleans up tablespace twice.  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: pg_regress cleans up tablespace twice.  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
Thanks for working on this.

At Wed, 17 Jun 2020 16:12:07 +0900, Michael Paquier <michael@paquier.xyz> wrote in 
> 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.

It look good to me as the Windows part. I agree that vcregress.pl
don't need to parse EXTRA_REGRESS_OPTS by allowing a bit more tight
bond between the caller sites of pg_regress and pg_regress.

> 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,

Agreed on probability. 

> 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.

Chaning to TAP sounds nice as a goal.

As the next step we need to amend GNUmakefile not to cleanup
tablespace for the four test items. Then somehow treat tablespaces at
non-default place?

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Fujii Masao
Дата:
Сообщение: Re: Review for GetWALAvailability()
Следующее
От: Masahiko Sawada
Дата:
Сообщение: Re: Resetting spilled txn statistics in pg_stat_replication