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
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 |
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 |