Re: walreceiver fails on asynchronous replica [EXTERNAL] [SEC=UNOFFICIAL]
От | Kyotaro Horiguchi |
---|---|
Тема | Re: walreceiver fails on asynchronous replica [EXTERNAL] [SEC=UNOFFICIAL] |
Дата | |
Msg-id | 20240301.103716.1999702877749634290.horikyota.ntt@gmail.com обсуждение исходный текст |
Ответ на | RE: walreceiver fails on asynchronous replica [EXTERNAL] [SEC=UNOFFICIAL] (Mark Schloss <Mark.Schloss@austrac.gov.au>) |
Ответы |
Re: walreceiver fails on asynchronous replica [EXTERNAL] [SEC=UNOFFICIAL]
|
Список | pgsql-general |
Hi, Mark. At Thu, 29 Feb 2024 04:39:49 +0000, Mark Schloss <Mark.Schloss@austrac.gov.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. [1] https://www.postgresql.org/message-id/CAFh8B%3DmozC%2Be1wGJq0H%3D0O65goZju%2B6ab5AU7DEWCSUA2OtwDg%40mail.gmail.com regards. -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-general по дате отправления: