|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> 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.
|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|