Re: Occasional tablespace.sql failures in check-world -jnn
От | Peter Eisentraut |
---|---|
Тема | Re: Occasional tablespace.sql failures in check-world -jnn |
Дата | |
Msg-id | c07e4250-75aa-341c-77f5-e415ce83e89d@enterprisedb.com обсуждение исходный текст |
Ответ на | Occasional tablespace.sql failures in check-world -jnn (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Occasional tablespace.sql failures in check-world -jnn
|
Список | pgsql-hackers |
On 2020-12-09 02:29, Andres Freund wrote: > I suspect this is related to the pg_upgrade test and the main regression > test running at the same time. We have the following in src/test/regress/GNUMakefile > > # Tablespace setup > > .PHONY: tablespace-setup > tablespace-setup: > echo $(realpath ./testtablespace) >> /tmp/tablespace.log > rm -rf ./testtablespace > mkdir ./testtablespace > ... > > which pg_upgrade triggers. Even though it, as far as I can tell, never > actually ends up putting any data in it: > > # Send installcheck outputs to a private directory. This avoids conflict when > # check-world runs pg_upgrade check concurrently with src/test/regress check. > # To retrieve interesting files after a run, use pattern tmp_check/*/*.diffs. > outputdir="$temp_root/regress" > EXTRA_REGRESS_OPTS="$EXTRA_REGRESS_OPTS --outputdir=$outputdir" > export EXTRA_REGRESS_OPTS > mkdir "$outputdir" > mkdir "$outputdir"/testtablespace > > It's not clear to me why we have this logic in the makefile at all? > Somebody taught pg_regress to do so, but only on windows... See > convert_sourcefiles_in(). I vaguely recall that this had something to do with SELinux (or something similar?), where it matters in what context you create a file or directory and then certain properties attach to it that are relevant to subsequent programs that run on it. Again, vague.
В списке pgsql-hackers по дате отправления: