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