Re: Should we remove "not fast" promotion at all?
От | Michael Paquier |
---|---|
Тема | Re: Should we remove "not fast" promotion at all? |
Дата | |
Msg-id | CAB7nPqT_yqdqgQOsKo2rVvOYrCkMyAAfzvJe0Qk-DVs4YmKKpg@mail.gmail.com обсуждение исходный текст |
Ответ на | Should we remove "not fast" promotion at all? (Fujii Masao <masao.fujii@gmail.com>) |
Ответы |
Re: Should we remove "not fast" promotion at all?
(Fujii Masao <masao.fujii@gmail.com>)
|
Список | 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
В списке pgsql-hackers по дате отправления: