Re: replay pause vs. standby promotion

From: Sergei Kornilov <sk(at)zsrv(dot)org>
To: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, Atsushi Torikoshi <atorik(at)gmail(dot)com>
Cc: Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: replay pause vs. standby promotion
Date: 2020-03-23 15:17:16
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


> You meant that the promotion request should cause the recovery
> to finish immediately even if there are still outstanding WAL records,
> and cause the standby to become the master?

Oh, I get your point. But yes, I expect that in case of promotion request during a pause, the user (me too) will want to have exactly the current state, not latest available in WALs.

Real usercase from my experience:
The user wants to update a third-party application. In case of problems, he wants to return to the old version of the application and the unchanged replica. Thus, it sets a pause on standby and performs an update. If all is ok - he will resume replay. In case of some problems he plans to promote standby.
But oops, standby will ignore promote signals during pause and we need get currect LSN from standby and restart it with recovery_target_lsn = ? and recovery_target_action = promote to achieve this state.

regards, Sergei

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Joel Mariadasan (jomariad) 2020-03-23 15:28:22 RE: ASLR support for Postgres12
Previous Message Alvaro Herrera 2020-03-23 15:16:22 Re: [Patch] pg_rewind: options to use restore_command from recovery.conf or command line