Re: Should we remove "not fast" promotion at all?

On Tue, Aug 6, 2013 at 11:20 AM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> On Tue, Aug 6, 2013 at 3:24 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>> Hi all,
>>
>> We discussed the $SUBJECT in the following threads:
>> http://www.postgresql.org/message-id/CA+TgmoZbR+WL8E7MF_KRp6fY4FD2pMr11TPiuyjMFX_Vtg1Wrw@mail.gmail.com
>> http://www.postgresql.org/message-id/CAHGQGwEBUvgcx8X+Z0Hh+VdwYcJ8KCuRuLt1jSsxeLxPcX=0_w@mail.gmail.com
>>
>> Our consensus seems to remove "not fast" promotion at all
>> because there is no use case for that promotion.
> Indeed, if two modes of promotion are available, it is not that
> user-friendly if pg_ctl does not support both directly.
>
> struct stat stat_buf;
>
> - if (stat(PROMOTE_SIGNAL_FILE, &stat_buf) == 0 ||
> - stat(FAST_PROMOTE_SIGNAL_FILE, &stat_buf) == 0)
> + /*
> + * In 9.1 and 9.2 the postmaster unlinked the promote file inside the
> + * signal handler. We now leave the file in place and let the Startup
> + * process do the unlink. This is the infrastructure for supporting
> + * various promotion modes in the future. This allows Startup to know
> + * the mode from the promote signal file that the postmaster left.
> + */
> + if (stat(PROMOTE_SIGNAL_FILE, &stat_buf) == 0)
> return true;
> Why not reshuffle this comment and remove references to 9.1 and 9.2?

I just left the old comment as it is. I'm OK with your suggestion.

> - /*
> - * In 9.1 and 9.2 the postmaster unlinked the promote
> file inside the
> - * signal handler. We now leave the file in place and
> let the Startup
> - * process do the unlink. This allows Startup to know
> whether we're
> - * doing fast or normal promotion. Fast promotion
> takes precedence.
> - */
> - if (stat(FAST_PROMOTE_SIGNAL_FILE, &stat_buf) == 0)
> - {
> - unlink(FAST_PROMOTE_SIGNAL_FILE);
> - unlink(PROMOTE_SIGNAL_FILE);
> - fast_promote = true;
> - }
> - else if (stat(PROMOTE_SIGNAL_FILE, &stat_buf) == 0)
> - {
> - unlink(PROMOTE_SIGNAL_FILE);
> - fast_promote = false;
> - }
> -
> ereport(LOG, (errmsg("received promote request")));
> -
> + unlink(PROMOTE_SIGNAL_FILE);
> Wouldn't it make sense to keep the call to stat() to check the file
> status before unlinking it?

Why do we need to check the existence of the file before removing it
here?

Regards,

--
Fujii Masao