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

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?
Something like that perhaps:
Leave the promote signal file in place and let the Startup do the
unlink. This infrastructure permits Startup to know the mode from the
promote signal file that postmaster left, keeping the door open for
support of multiple promotion modes in the future.

-               /*
-                * 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?
-- 
Michael