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  (Michael Paquier <michael@paquier.xyz>)
Список 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 по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Printing backtrace of postgres processes
Следующее
От: "lchch1990@sina.cn"
Дата:
Сообщение: Re: Wrong HINT during database recovery when occur a minimal wal.