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

UNOFFICIAL
Hello,

Thanks for looking at this. I think I complicated things by including barman. I was just wanting to point out each primary streams to two locations - the walreceiver on the replica and the walreciver used by barman. We think the reason the barman WAL-receiver didn't fail is because there is no apply of the WAL in Barman but the Standby is applying and it's WAL-receiver got terminated, so the barman server can be taken out of this picture completely, they were just there as a by-product in trying to determine the effect. We are only interested in the killing of the standby wal-receiver and that the pg_waldump showed the failing lsn was a commit.

Thanks

UNOFFICIAL

-----Original Message-----
From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Sent: Wednesday, 28 February 2024 5:09 PM
To: Mark Schloss <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]

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

**********************************************************************
Please note that your email address is known to AUSTRAC for the
purposes of communicating with you. The information transmitted in
this e-mail is for the use of the intended recipient only and may
contain confidential and/or legally privileged material. If you have
received this information in error you must not disseminate, copy or
take any action on it and we request that you delete all copies of
this transmission together with attachments and notify the sender.

This footnote also confirms that this email message has been swept for
the presence of computer viruses.
**********************************************************************