Feedback-ID: ia2694551:Fastmail
Date: Wed, 18 Jan 2023 10:59:11 +0100
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: "Drouvot, Bertrand" <bertranddrouvot.pg@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Helper functions for wait_for_catchup() in Cluster.pm
Message-ID: <20230118095911.bscvvnyu2ywhison@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <e8a56fac-2f23-141c-d9a5-731fd01115b2@gmail.com>
Archived-At: <https://www.postgresql.org/message-id/20230118095911.bscvvnyu2ywhison%40alvherre.pgsql>
Precedence: bulk

On 2023-Jan-18, Drouvot, Bertrand wrote:

> The current calls are done that way:
> 
> wait_for_replay_catchup called:
> - 8 times with write LSN as an argument
> - 1 time with insert LSN as an argument
> - 16 times with flush LSN as an argument

> So it looks like that providing a node as a second argument
> would not help for the wait_for_replay_catchup() case.

... unless we changed the calls that wait for reply that use write or
insert so that they use flush instead.  Surely everything should still
work, right?  Flushing would still occur, either right after the write
(as the transaction commits) or ~200ms afterwards when WAL writer
catches up to that point.

I suppose this may fail to be true if there is some test that is
specifically testing whether writing WAL without flushing works, which
should rare enough, but if it does exist, in that one place we can use
the underlying wait_for_catchup().

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/