Re: Remove non-fast promotion Re: Should we remove a fallbackpromotion? take 2 - Mailing list pgsql-hackers

On Mon, Apr 20, 2020 at 03:26:16PM +0900, Fujii Masao wrote:
> Patch attached. I will add this into the first CF for v14.

Thanks!

> -    if (IsPromoteSignaled())
> +    /*
> +     * In 9.1 and 9.2 the postmaster unlinked the promote file inside the
> +     * signal handler. It now leaves the file in place and lets the
> +     * Startup process do the unlink.
> +     */
> +    if (IsPromoteSignaled() && stat(PROMOTE_SIGNAL_FILE, &stat_buf) == 0)
>      {
> -        /*
> -         * In 9.1 and 9.2 the postmaster unlinked the promote file inside the
> -         * signal handler. It now leaves the file in place and lets the
> -         * Startup process do the unlink. This allows Startup to know whether
> -         * it should create a full checkpoint before starting up (fallback
> -         * mode). Fast promotion takes precedence.
> -         */
> -        if (stat(PROMOTE_SIGNAL_FILE, &stat_buf) == 0)
> -        {
> -            unlink(PROMOTE_SIGNAL_FILE);
> -            unlink(FALLBACK_PROMOTE_SIGNAL_FILE);
> -            fast_promote = true;
> -        }
> -        else if (stat(FALLBACK_PROMOTE_SIGNAL_FILE, &stat_buf) == 0)
> -        {
> -            unlink(FALLBACK_PROMOTE_SIGNAL_FILE);
> -            fast_promote = false;
> -        }
> -
>          ereport(LOG, (errmsg("received promote request")));
> -
> +        unlink(PROMOTE_SIGNAL_FILE);

On HEAD, this code means that it is possible to end recovery just by
sending SIGUSR2 to the startup process.  With your patch, this code
now means that in order to finish recovery you need to send SIGUSR2 to
the startup process *and* to create the promote signal file.  Is that
really what you want?
--
Michael