Re: Should we remove "not fast" promotion at all?

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, Tomonari Katsumata <t(dot)katsumata1122(at)gmail(dot)com>, Tomonari Katsumata <katsumata(dot)tomonari(at)po(dot)ntts(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Should we remove "not fast" promotion at all?
Date: 2013-08-07 13:26:53
Message-ID: CAHGQGwGz=oe1SmxBQy_C8-OJ285Ss_RmF9gqaBDV_R=pS3uypQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Aug 6, 2013 at 1:07 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Fujii Masao <masao(dot)fujii(at)gmail(dot)com> writes:
>> On Tue, Aug 6, 2013 at 11:40 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
>>> FWIW I'd rather keep plain promotion for a release or two. TBH, I have a
>>> 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.
>
> It would be silly to add such an option if we want to remove the old mode
> in a release or two.

Without such an option, a user cannot easily trigger the "normal" promotion
when we find some problems in fast promotion. In this case, a user needs to
create the "promote" file and send the SIGUSR1 signal to postmaster by hand.
Or needs to execute pg_ctl promote by using old version (e.g., 9.2) of pg_ctl.
Seems confusing.

Regards,

--
Fujii Masao

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2013-08-07 13:46:27 Re: [9.3 bug] disk space in pg_xlog increases during archive recovery
Previous Message Dimitri Fontaine 2013-08-07 12:39:16 Re: updated emacs configuration