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

Предыдущее
От: Bharath Rupireddy
Дата:
Сообщение: Re: pg_receivewal starting position
Следующее
От: Bharath Rupireddy
Дата:
Сообщение: Re: Allow pg_signal_backend members to use pg_log_backend_memory_stats().