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_b97Yc3FXw+f5U+DFpcC10WYwt5Lej4PpPaijQ_UZLVYd0g@mail.gmail.com
Whole thread Raw
In response to Re: TAP test for recovery_end_command  ("Euler Taveira" <euler@eulerto.com>)
Responses Re: TAP test for recovery_end_command  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Mon, Sep 13, 2021 at 8:39 PM Euler Taveira <euler@eulerto.com> wrote:
>
> On Mon, Sep 13, 2021, at 10:09 AM, Amul Sul wrote:
>
> Yeah, added that test too. I triggered the restartpoint via a
> CHECKPOINT command in the attached version.
>
> +# archive_cleanup_command executed with every restart points
> +ok( !-f "$archive_cleanup_command_file",
> + 'archive_cleanup_command not executed yet');
>
> Why are you including a test whose result is known? Fresh cluster does
> not contain archive_cleanup_command.done or recovery_end_command.done.
>

Make sense, removed in the attached version.

> +# Checkpoint will trigger restart point on standby.
> +$standby3->safe_psql('postgres', q{CHECKPOINT});
> +ok(-f "$archive_cleanup_command_file",
> + 'archive_cleanup_command executed on checkpoint');
>
> Is this test reliable?
>

I think yes, it will be the same as you are suggesting a shutdown
which eventually performs a checkpoint. That checkpoint on the
recovery server performs the restart point instead. Still, there could
be a case where archive_cleanup_command execution could be skipped,
if there is no record replied after the previous restart point, which
could happen in case of shutdown as well. Hope that makes sense.

Regards,
Amul

Attachment

pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: straightening out backend process startup
Next
From: Andres Freund
Date:
Subject: Re: Don't clean up LLVM state when exiting in a bad way