Re: [RFC] building postgres with meson - v12

From: Andres Freund <andres(at)anarazel(dot)de>
To: Justin Pryzby <pryzby(at)telsasoft(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, samay sharma <smilingsamay(at)gmail(dot)com>, Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com>
Subject: Re: [RFC] building postgres with meson - v12
Date: 2022-08-28 20:37:41
Message-ID: 20220828203741.mvseeiw2e56fpmni@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2022-08-28 20:42:24 Slight refactoring of state check in pg_upgrade check_ function
Previous Message Peter Geoghegan 2022-08-28 18:38:09 Re: effective_multixact_freeze_max_age issue