Re: TAP test for recovery_end_command
От | Amul Sul |
---|---|
Тема | Re: TAP test for recovery_end_command |
Дата | |
Msg-id | CAAJ_b97nAt6Ve+AqBeik2vg-c+azNzxQkp5Kd2hLE_NF+=AWGA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: TAP test for recovery_end_command (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: TAP test for recovery_end_command
|
Список | pgsql-hackers |
On Wed, Oct 20, 2021 at 11:09 AM Michael Paquier <michael@paquier.xyz> wrote: > > 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. > Understood, moved tests to 002_archiving.pl in the attached version. > +$standby4->append_conf('postgresql.conf', > + "recovery_end_command = 'echo recovery_ended > /non_existing_dir/file'"); > I am wondering how this finishes on Windows. My colleague Neha Sharma has confirmed that the attached version is passing on the Windows. Regards, Amul
Вложения
В списке pgsql-hackers по дате отправления: