Re: Run pg_amcheck in 002_pg_upgrade.pl and 027_stream_regress.pl?

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Run pg_amcheck in 002_pg_upgrade.pl and 027_stream_regress.pl?
Дата
Msg-id YkuDPrFHGHcq153O@paquier.xyz
обсуждение исходный текст
Ответ на Run pg_amcheck in 002_pg_upgrade.pl and 027_stream_regress.pl?  (Andres Freund <andres@anarazel.de>)
Ответы Re: Run pg_amcheck in 002_pg_upgrade.pl and 027_stream_regress.pl?
Список pgsql-hackers
On Sun, Apr 03, 2022 at 11:53:03AM -0700, Andres Freund wrote:
> It seems $subject would have a chance of catching some of these bugs, as well
> as exposing amcheck to a database with a bit more varied content?

Makes sense to me to extend that.

> Depending on the cost it might make sense to do this optionally, via
> PG_TEST_EXTRA?

Yes, it would be good to check the difference in run-time before
introducing more.  A logical dump of the regression database is no
more than 15MB if I recall correctly, so my guess is that most of the
runtime is still going to be eaten by the run of pg_regress.
--
Michael

Вложения

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

Предыдущее
От: Tatsuo Ishii
Дата:
Сообщение: Re: [HACKERS] WIP aPatch: Pgbench Serialization and deadlock errors
Следующее
От: Mark Dilger
Дата:
Сообщение: Re: Granting SET and ALTER SYSTE privileges for GUCs