Horton

Re: pgsql: Add TAP test for archive_cleanup_command and recovery_end_comman

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Michael Paquier <michael@paquier.xyz>, pgsql-hackers@lists.postgresql.org
Date: 2022-04-07T17:57:45Z
Lists: pgsql-hackers 
Andres Freund <andres@anarazel.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

Commits

  1. Fix second race condition in 002_archiving.pl with archive_cleanup_command

  2. Fix race in TAP test 002_archiving.pl when restoring history file

  3. Don't retry restore_command while reading ahead.

  4. Add TAP test for archive_cleanup_command and recovery_end_command