RE: Race condition with restore_command on streaming replica - Mailing list pgsql-general

From Brad Nicholson
Subject RE: Race condition with restore_command on streaming replica
Date
Msg-id OF3D6E4924.2966A015-ON85258623.0059D4FA-85258623.005A4D01@notes.na.collabserv.com
Whole thread Raw
In response to Re: Race condition with restore_command on streaming replica  (Dilip Kumar <dilipbalaut@gmail.com>)
Responses Re: Race condition with restore_command on streaming replica  (Leo Jin <leo.jin@enterprisedb.com>)
List pgsql-general

Dilip Kumar <dilipbalaut@gmail.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.



pgsql-general by date:

Previous
From: Adrian Klaver
Date:
Subject: Re: I have just downloaded Postgre SQL and "pgadmin 4" doesn't open.
Next
From: Ecenur Corlu
Date:
Subject: Re: I have just downloaded Postgre SQL and "pgadmin 4" doesn't open.