From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
cc: Andrew Dunstan <andrew@dunslane.net>,
        Mark Dilger <mark.dilger@enterprisedb.com>,
        Noah Misch <noah@leadboat.com>,
        PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Fixing WAL instability in various TAP tests
In-reply-to: <2852500.1632850031@sss.pgh.pa.us>
References: <32A1FDD1-9C7B-43B1-B3EE-49198DD3F887@enterprisedb.com>
 <20210925052151.GA4082552@rfd.leadboat.com>
 <2E9D28A3-1B54-446B-AC12-3BF86A2B522A@enterprisedb.com>
 <2502590.1632579467@sss.pgh.pa.us>
 <2B4C64CF-EE3F-474B-9685-6A927E5E49AE@enterprisedb.com>
 <20210925160039.GA4134968@rfd.leadboat.com>
 <193AC968-C348-4D81-88BC-384560F87500@enterprisedb.com>
 <C1D227C2-C271-4310-8C85-C5368C298622@enterprisedb.com>
 <2769443.1632773967@sss.pgh.pa.us> <YVJXEf119KrJDFdq@paquier.xyz>
 <2801531.1632795612@sss.pgh.pa.us> <2852500.1632850031@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Tue, 28 Sep 2021 13:27:11 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2854601.1632852664.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 28 Sep 2021 14:11:04 -0400
Message-ID: <2854602.1632852664@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2854602.1632852664%40sss.pgh.pa.us>
Precedence: bulk

I wrote:
> So there's more than one symptom, but in any case it seems like
> we have an issue in WAL replay.  I wonder whether it's bloom's fault
> or a core bug.

Actually ... I bet it's just the test script's fault.  It waits for the
standby to catch up like this:

	my $caughtup_query =3D
	  "SELECT pg_current_wal_lsn() <=3D write_lsn FROM pg_stat_replication WH=
ERE application_name =3D '$applname';";
	$node_primary->poll_query_until('postgres', $caughtup_query)
	  or die "Timed out while waiting for standby 1 to catch up";

which seems like completely the wrong condition.  Don't we need the
standby to have *replayed* the WAL, not merely written it to disk?

I'm also wondering why this doesn't use wait_for_catchup, instead
of reinventing the query to use.

			regards, tom lane