Re: Should we remove "not fast" promotion at all?
| От | Tomonari Katsumata |
|---|---|
| Тема | Re: Should we remove "not fast" promotion at all? |
| Дата | |
| Msg-id | CAC55fYfT8_so+GVA0i_ZrpvhbgT0=Q=QBoWqWFznpVdV4st1sg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Should we remove "not fast" promotion at all? (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Should we remove "not fast" promotion at all?
|
| Список | pgsql-hackers |
Hi,
2013/8/6 Tom Lane <tgl@sss.pgh.pa.us>
How about giving trigger_file an ability to chose "fast promote" and "normal promote"Fujii Masao <masao.fujii@gmail.com> writes:
> On Tue, Aug 6, 2013 at 11:40 AM, Andres Freund <andres@2ndquadrant.com> wrote:>> FWIW I'd rather keep plain promotion for a release or two. TBH, I have aIt would be silly to add such an option if we want to remove the old mode
>> bit of trust issues regarding the new method, and I'd like to be able to
>> test potential issues against a stock postgres by doing a normal instead
>> of a fast promotion.
> So we should add new option specifying the promotion mode, into pg_ctl?
> Currently pg_ctl cannot trigger the normal promotion.
in a release or two.
I think what Andres is suggesting is to leave it as-is for 9.4 and then
remove the old code in 9.5 or 9.6. Which seems prudent to me.
like the triggerfile of pg_standby.
It means that if the contents of the trigger_file is empty or 'smart' then do "normal promote",
and it's 'fast' then do "fast promote".
I think this change would be smaller than change to pg_ctl.
And this would allow us to treat ${PGDATA}/promote and trigger_file only.(because ${PGDATA}/fast_promote is not created automatically)
regards,
---------------
---------------
Tomonari Katsumata
В списке pgsql-hackers по дате отправления: