On Tue, 2022-11-01 at 08:49 -0500, Ron wrote: > Primary has crashed, according to OP; it's not coming back any time soon. And thus you promote > Secondary to be New Primary, and go about your work. When the Old Primary comes back up > (hours or days later), you do a pg_basebackup to make it the New Secondary.
There was no word about failover or "not coming back any time soon" (that's why I asked for clarification in my answer). In fact, PostgreSQL will often undergo crash recovery and come back up automatically. See the parameter "restart_after_crash", which defaults to "on".
Sorry, It was my mistake not to mention the failover to the Standby required.
I mean when the Primary Server crashes due to a H/W failure or whatever other reason, Then in my case I am forced to promote the Standby server as Primary until the old primary server H/W vendor replaces the hardware component( it may vary from hours to days as pre SLA terms with H/W vendor).
In this scenario any transactions happened in crashed Primary server which were not transferred due to the delay in transfer to the Standby server. But I am in need to promote the Standby to Primary and it will run for another one day or two, until my Old crashed server failed component is replaced with a new H/W part.
So there will be an inconsistency in the data between the current Primary ( promoted standby) and my recovered /repaired old server ( which was primary before the crash).
How to handle this data inconsistency or what best mechanism needs to be implemented if you were me in this use case scenario?