Re: TAP test for recovery_end_command
От | Michael Paquier |
---|---|
Тема | Re: TAP test for recovery_end_command |
Дата | |
Msg-id | YW+rdXnr7OnGxFhS@paquier.xyz обсуждение исходный текст |
Ответ на | Re: TAP test for recovery_end_command (Amul Sul <sulamul@gmail.com>) |
Ответы |
Re: TAP test for recovery_end_command
|
Список | pgsql-hackers |
On Wed, Oct 06, 2021 at 06:49:10PM +0530, Amul Sul wrote: > Thanks for the suggestion, added the same in the attached version. Hmm. The run-time of 020_archive_status.p bumps from 4.7s to 5.8s on my laptop, so the change is noticeable. I agree that it would be good to have more coverage for those commands, but I also think that we should make things cheaper if we can, particularly knowing that those commands just touch a file. This patch creates two stanbys for its purpose, but do we need that much? On top of that, 020_archive_status.pl does not look like the correct place for this set of tests. 002_archiving.pl would be a better candidate, where we already have two standbys that get promoted, so you could have both the failure and success cases there. There should be no need for extra wait phases either. +$standby4->append_conf('postgresql.conf', + "recovery_end_command = 'echo recovery_ended > /non_existing_dir/file'"); I am wondering how this finishes on Windows. -- Michael
Вложения
В списке pgsql-hackers по дате отправления: