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
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 |