Re: pgsql: Switch pg_verify_checksums back to a blacklist

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: pgsql: Switch pg_verify_checksums back to a blacklist
Дата
Msg-id 20181130053555.GF2267@paquier.xyz
обсуждение исходный текст
Ответы Re: pgsql: Switch pg_verify_checksums back to a blacklist  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
Список pgsql-hackers
On Fri, Nov 30, 2018 at 01:36:43AM +0000, Michael Paquier wrote:
> Switch pg_verify_checksums back to a blacklist
>
> This basically reverts commit d55241af705667d4503638e3f77d3689fd6be31,
> leaving around a portion of the regression tests still adapted with
> empty relation files, and corrupted cases.  This is also proving to be
> failing to check properly relation files located in a non-default
> tablespace path.

So, jacana is not in love with this commit for the tests:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jacana&dt=2018-11-30%2003%3A34%3A23

The error is here:
server started
# Postmaster PID for node "node_checksum" is 14820
error running SQL: 'psql:<stdin>:1: ERROR:  directory

"/home/pgrunner/bf/root/HEAD/pgsql.build/src/bin/pg_verify_checksums/tmp_check/t_002_actions_node_checksum_data/ts_corrupt_dir"
does not exist'

What visibly happens is that we create a path for a tablespace which
will include a corrupted table.  However psql tries to run CREATE
TABLESPACE but gets back a complain about the path not existing.  The
thing is that mkdir has been used beforehand so the path should be
here.

I have tested this set of TAP tests on my Windows 10 VM with MSVC 2015
before commit and those tests passed.  Could it be that jacana is using
msys, so a trick similar to what is used in 014_unlogged_reinit.pl is
necessary?

Andrew, could you confirm if the patch attached works?  I would prefer
not doing a blind fix if possible..
--
Michael

Вложения

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

Предыдущее
От: Nikhil Sontakke
Дата:
Сообщение: Re: [HACKERS] logical decoding of two-phase transactions
Следующее
От: David Rowley
Дата:
Сообщение: Re: Planning time of Generic plan for a table partitioned into a lot