From: Tom Lane <tgl@sss.pgh.pa.us>
To: Matthias van de Meent <boekewurm+postgres@gmail.com>
cc: Alvaro Herrera <alvherre@alvh.no-ip.org>,
        PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: standby recovery fails (tablespace related) (tentative patch and
 discussion)
In-reply-to: 
 <CAEze2Wj5nau_qpjbwihvmXLfkAWOZ5TKdbnqOc6nKSiRJEoPyQ@mail.gmail.com>
References: <20220720105049.jk52353p6ce35idb@alvherre.pgsql>
 <20220727185449.2ixbv3fe4mxuzpwk@alvherre.pgsql>
 <CAEze2Wj5nau_qpjbwihvmXLfkAWOZ5TKdbnqOc6nKSiRJEoPyQ@mail.gmail.com>
Comments: In-reply-to Matthias van de Meent <boekewurm+postgres@gmail.com>
	message dated "Thu, 28 Jul 2022 20:04:38 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3560218.1659045432.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 28 Jul 2022 17:57:12 -0400
Message-ID: <3560219.1659045432@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3560219.1659045432%40sss.pgh.pa.us>
Precedence: bulk

Matthias van de Meent <boekewurm+postgres@gmail.com> writes:
> I'd like to bring to your attention that the test that was introduced
> with 9e4f914b seem to be flaky in FreeBSD 13 in the CFBot builds: it
> sometimes times out while waiting for the secondary to catch up. Or,
> at least I think it does, and I'm not too familiar with TAP failure
> outputs: it returns with error code 29 and logs that I'd expect when
> the timeout is reached.

It's also failing in the buildfarm, eg

https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=3Dconchuela&dt=3D2=
022-07-28%2020%3A57%3A50

Looks like only conchuela so far, reinforcing the idea that we're
only seeing it on FreeBSD.  I'd tentatively bet on a timing problem
that requires some FreeBSD scheduling quirk to manifest; we've seen
such quirks before.

			regards, tom lane