Re: Race condition in recovery?

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Race condition in recovery?
Дата
Msg-id CA+TgmobtyLhmnk=Dm2nCG07vvSYu89h9VCJv6STC1DvXfkd37Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Race condition in recovery?  (Dilip Kumar <dilipbalaut@gmail.com>)
Ответы Re: Race condition in recovery?  (Dilip Kumar <dilipbalaut@gmail.com>)
Список pgsql-hackers
On Sat, May 22, 2021 at 12:45 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> No, in my original scenario also the new standby was not old primary,
> I had 3 nodes
> node1-> primary, node2 -> standby1, node3-> standby2
> node2 promoted as a new primary and node3's local WAL was removed (so
> that it has to stream checkpoint record from new primary and then
> remaining everything happens as you explain in remaining steps).

Oh, OK. I misunderstood. I think it could happen that way, though.

> I haven't tested this, but I will do that.  But now we are on the same
> page about the cause of the actual problem I reported.

Yeah, sorry, I just didn't understand the exact chain of events before.

> For my original case, both standby1 and standby2 are connected to the
> primary.  Now, standby1 is promoted and standby2 is shut down. And,
> before restarting, all the local WAL of the standby2 is removed so
> that it can follow the new primary. The primary info and restore
> command for standby2 are changed as per the new primary(standby1).

One thing I don't understand is why the final WAL segment from the
original primary didn't end up in the archive in this scenario. If it
had, then we would not have seen the issue in that case.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Installation of regress.so?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Subscription tests fail under CLOBBER_CACHE_ALWAYS