Re: Helper functions for wait_for_catchup() in Cluster.pm

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: "Drouvot, Bertrand" <bertranddrouvot(dot)pg(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Helper functions for wait_for_catchup() in Cluster.pm
Date: 2023-01-18 09:59:11
Message-ID: 20230118095911.bscvvnyu2ywhison@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message shiy.fnst@fujitsu.com 2023-01-18 10:02:28 RE: Update comments in multixact.c
Previous Message David Rowley 2023-01-18 09:49:10 Re: Add proper planner support for ORDER BY / DISTINCT aggregates