Re: TAP test for recovery_end_command

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Amul Sul <sulamul(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Euler Taveira <euler(at)eulerto(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: TAP test for recovery_end_command
Date: 2021-10-20 05:39:01
Message-ID: YW+rdXnr7OnGxFhS@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2021-10-20 05:40:14 Re: [PATCH] Prefer getenv("HOME") to find the UNIX home directory
Previous Message Michael Paquier 2021-10-20 05:20:21 Re: LogicalChanges* and LogicalSubxact* wait events are never reported