Date: Fri, 8 Apr 2022 16:56:08 -0700
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Michael Paquier <michael@paquier.xyz>,
	Thomas Munro <thomas.munro@gmail.com>,
	pgsql-hackers@lists.postgresql.org
Subject: Re: pgsql: Add TAP test for archive_cleanup_command and
 recovery_end_comman
Message-ID: <20220408235608.ppdq5vcb3kjk5yu5@alap3.anarazel.de>
References: <E1mfuYK-0004Bn-7O@gemulon.postgresql.org>
 <3385143.1649353230@sss.pgh.pa.us>
 <20220407175210.q44nnrvkovprxo2a@alap3.anarazel.de>
 <3386734.1649354265@sss.pgh.pa.us>
 <20220407181202.7xa573u6e2z5dbdz@alap3.anarazel.de>
 <4015413.1649454951@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4015413.1649454951@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/20220408235608.ppdq5vcb3kjk5yu5%40alap3.anarazel.de>
Precedence: bulk

Hi,

On 2022-04-08 17:55:51 -0400, Tom Lane wrote:
> After seeing skink's results, I tried running that test under valgrind
> here, and it fails just like that every time.  skink's history allows
> us to bound the failure introduction between 79b716cfb7 and
> d7ab2a9a3c, which I think makes it just about certain that it was
> 5dc0418fab (Prefetch data referenced by the WAL, take II), though I've
> not bisected to be 100% sure.

I've tested it, it's 5dc0418fab that makes the difference. I reduced the cycle
time by making initdb not go through valgrind, but have normal postgres
instances go through it.


> On the whole, I'm not sure that the WAL prefetch logic is noticeably
> more stable than when we booted it out last year :-(.

IDK. Last year's issues seems to have largely been caused by a flaky
machine. And a bug, if it's that, in some archiving corner case that's not
normally reached during tests...

Greetings,

Andres Freund