Re: walreceiver fails on asynchronous replica [EXTERNAL] [SEC=UNOFFICIAL]

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: Mark(dot)Schloss(at)austrac(dot)gov(dot)au
Cc: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: walreceiver fails on asynchronous replica [EXTERNAL] [SEC=UNOFFICIAL]
Date: 2024-02-28 06:09:16
Message-ID: 20240228.150916.2195234979663167268.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

At Wed, 28 Feb 2024 03:23:37 +0000, Mark Schloss <Mark(dot)Schloss(at)austrac(dot)gov(dot)au> wrote in
> Thank you for your reply. I can confirm there were no changes made to the config of the replica.

Okay.

> Is there any significance in the parameters in the commit record -
> 'inval msgs: catcache 21; sync'.

I think it is not relevant.

> - The walreceiver on the barman server did not fail but the WAL file does not contain the commit transaction

I don't have detailed knowledge of barman's behavior, but it seems to
be quite normal for barman to write out only on receiving a commit
record. What I don't understand here is how those WAL files on the
barman server are related to the failed replicas.

From the information you provided, I guess that the replicas somehow
obtain the currently-written WAL file from the barman server at a
certain time through a route unknown to me, but you seem to know
that. I think that relationship has not been explained here.

Could you explain the routes and timings that WAL files are copied
between the servers?

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Shanti-Dominique 2024-02-28 11:05:27 Efficient rows filter for array inclusion with gin index
Previous Message Ron Johnson 2024-02-28 05:59:20 Re: PostgreSQL Guard