Re: [RFC] building postgres with meson - v12

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: [RFC] building postgres with meson - v12
Дата
Msg-id 20220828203741.mvseeiw2e56fpmni@awork3.anarazel.de
обсуждение исходный текст
Ответ на Re: [RFC] building postgres with meson - v12  (Justin Pryzby <pryzby@telsasoft.com>)
Ответы Re: [RFC] building postgres with meson - v12  (Justin Pryzby <pryzby@telsasoft.com>)
Список pgsql-hackers
Hi,

On 2022-08-28 12:08:07 -0500, Justin Pryzby wrote:
> with_temp_install is repeated twice in prove_check:
>
> > Subject: [PATCH v12 02/15] Split TESTDIR into TESTLOGDIR and TESTDATADIR
> >
> > -   TESTDIR='$(CURDIR)/tmp_check' $(with_temp_install)
> >     PGPORT='6$(DEF_PGPORT)' \
> > +   TESTLOGDIR='$(CURDIR)/tmp_check/log' $(with_temp_install) \
> > +   TESTDATADIR='$(CURDIR)/tmp_check' $(with_temp_install) \
> > +   PGPORT='6$(DEF_PGPORT)' \

Oops, must have screwed up resolving a conflict...


> Before running an individual test like "meson test recovery/017_shm",
> it's currently necessary to first manually run "meson test tmp_install".
> Is it possible to make that happen automatically ?

Not in a trivial way that I found. We don't want to reinstall all the time -
it's *quite* expensive on older machines. We could have a lock file in the
test setup so that the first test run installs it, with the others getting
stalled, but that has pretty obvious disadvantages too (like the test timing
being distorted).

Medium term I think we should consider simply not needing the temp install.

FWIW, if you can do the above as 'meson test tmp_install recovery/017_shm'.


> You're running tap tests via a python script.  There's no problem with
> that, but it's different from what's done by the existing makefiles.
> I was able to remove the python indirection - maybe that's better to
> talk about on the CI thread?  That moves some setup for TAP tests
> (TESTDIR, PATH, cd) from Makefile into the existing perl, which means
> less duplication.

I'm doubtful it's worth removing. You'd need to move removing the files from
the last run into both pg_regress and the tap test infrastructure. And I do
think it's nice to afterwards have markers which tests failed, so we can only
collect their logs.

Greetings,

Andres Freund



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

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: effective_multixact_freeze_max_age issue
Следующее
От: Daniel Gustafsson
Дата:
Сообщение: Slight refactoring of state check in pg_upgrade check_ function