RE: Race condition with restore_command on streaming replica

Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote on 2020/11/15 04:47:12 AM:
> I am not sure how Patroni does it internally, can you explain the
> scenario in more detail? Suppose you are executing the promote on m-1
> and if the promotion is successful it will switch the timeline and it
> will create the timeline history file. Now, once the promotion is
> successful if we change the primary_conninfo on the m-2 then it will
> restart the walsender and look for the latest .history file which it
> should find either from direct streaming or through the
> restore_command. If you are saying that m-2 tried to look for the
> history file before m-1 created it then it seems like you change the
> primary_conninfo on m-2 before the m-1 promotion got completed.

Patroni first issues a fast shutdown to m-0. Once that completes, it
issues a promote on m-1.

In this case, m-2 is not connecting directly to to m-0 or m-1 via a
hostname, it is connecting to a virtual layer that routes the connectivity
to the current primary. This does not change.

Brad.