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-03-01 01:37:16 |
Message-ID: | 20240301.103716.1999702877749634290.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi, Mark.
At Thu, 29 Feb 2024 04:39:49 +0000, Mark Schloss <Mark(dot)Schloss(at)austrac(dot)gov(dot)au> wrote in
> 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.
It seems that an issue raised in the -hackers thread [1] might be the
same issue as yours. The discussion might be a help for you, although
it's not clear what is happening yet.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Laurenz Albe | 2024-03-01 09:18:19 | Re: Content for talk on Postgres Type System at PostgresConf |
Previous Message | Paul Jungwirth | 2024-02-29 23:22:27 | Re: Content for talk on Postgres Type System at PostgresConf |