Re: Should we remove "not fast" promotion at all? - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: Should we remove "not fast" promotion at all?
Date
Msg-id CAHGQGwHrADcSui3S5gRkrSVtA5c3od68W-v0JAtBPXpL9xGxwA@mail.gmail.com
Whole thread Raw
In response to Re: Should we remove "not fast" promotion at all?  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: Should we remove "not fast" promotion at all?  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
On Tue, Aug 6, 2013 at 11:20 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Tue, Aug 6, 2013 at 3:24 AM, Fujii Masao <masao.fujii@gmail.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



pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: HeapTupleSatisfiesDirty fails to test HEAP_XMAX_IS_LOCKED_ONLY for TransactionIdIsInProgress(...)
Next
From: Fujii Masao
Date:
Subject: Re: Should we remove "not fast" promotion at all?