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

From: "Drouvot, Bertrand" <bertranddrouvot(dot)pg(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
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-19 08:10:59
Message-ID: 2198c60b-9a6c-79a5-bb35-81f1ac3113bd@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 1/18/23 10:59 AM, Alvaro Herrera wrote:
> 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.

That's a good idea, thanks! Please find attached V2 doing so.

> Surely everything should still
> work, right?

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,

I don't see this kind of test.

Please note that V2 does not contain wait_for_flush_catchup() and
wait_for_sent_catchup() anymore as: 1) they are not used yet
and 2) it lets to their author (if any) decide the node->lsn() mode to be used.

This is also mentioned as a comment in V2.

Regards,

--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

Attachment Content-Type Size
v2-0001-wait_for_catchup_helper_functions.patch text/plain 14.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2023-01-19 08:11:20 Re: Collation version tracking for macOS
Previous Message Michael Paquier 2023-01-19 07:56:05 Re: [EXTERNAL] Re: [PATCH] Support using "all" for the db user in pg_ident.conf