Re: TAP test for recovery_end_command - Mailing list pgsql-hackers

From Amul Sul
Subject Re: TAP test for recovery_end_command
Date
Msg-id CAAJ_b97nAt6Ve+AqBeik2vg-c+azNzxQkp5Kd2hLE_NF+=AWGA@mail.gmail.com
Whole thread Raw
In response to Re: TAP test for recovery_end_command  (Michael Paquier <michael@paquier.xyz>)
Responses Re: TAP test for recovery_end_command
List 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

Attachment

pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: pg_receivewal starting position
Next
From: Bharath Rupireddy
Date:
Subject: Re: Allow pg_signal_backend members to use pg_log_backend_memory_stats().