Re: pgsql: Add TAP test for archive_cleanup_command and recovery_end_comman

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: pgsql: Add TAP test for archive_cleanup_command and recovery_end_comman
Date: 2022-04-07 17:57:45
Message-ID: 3386734.1649354265@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2022-04-07 13:40:30 -0400, Tom Lane wrote:
>> This test is sending a CHECKPOINT command to the standby and
>> expecting it to run the archive_cleanup_command, but it looks
>> like the standby did not actually run any checkpoint:
>> ...
>> I wondered if the recent pg_stats changes could have affected this, but I
>> don't really see how.

> I don't really see either. It's a bit more conceivable that the recovery
> prefetching changes could affect the timing sufficiently?

Oh, that's at least a little plausible.

> I guess we'll have to wait and see what the frequency of the problem is?

Yeah, with only one instance it could just be cosmic rays or something.
However, assuming it is real, I guess I wonder why we don't say
CHECKPOINT_FORCE in standby mode too.

regards, tom lane

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Petr Jelinek 2022-04-07 18:07:17 Re: API stability [was: pgsql: Fix possible recovery trouble if TRUNCATE overlaps a checkpoint.]
Previous Message Andres Freund 2022-04-07 17:52:10 Re: pgsql: Add TAP test for archive_cleanup_command and recovery_end_comman

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2022-04-07 18:02:41 Re: test/isolation/expected/stats_1.out broken for me
Previous Message Andres Freund 2022-04-07 17:53:59 Re: [PATCH] Add native windows on arm64 support