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

From Fujii Masao
Subject Re: Remove non-fast promotion Re: Should we remove a fallbackpromotion? take 2
Date
Msg-id 3e58d54b-96d9-80db-c213-6b5c2fe7b5e0@oss.nttdata.com
Whole thread Raw
In response to Re: Remove non-fast promotion Re: Should we remove a fallbackpromotion? take 2  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Remove non-fast promotion Re: Should we remove a fallbackpromotion? take 2
List pgsql-hackers

On 2020/04/21 10:59, Michael Paquier wrote:
> 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);

Thanks for reviewing the patch!

> On HEAD, this code means that it is possible to end recovery just by
> sending SIGUSR2 to the startup process.

Yes, in this case, non-fast promotion is triggered.

> 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.

Yes, but isn't this the same as the way to trigger fast promotion in HEAD?

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: WIP: WAL prefetch (another approach)
Next
From: Andres Freund
Date:
Subject: Re: design for parallel backup