Thread: Re: [COMMITTERS] pgsql: Make fast promotion the default promotion mode.
On Wed, Apr 24, 2013 at 8:49 PM, Simon Riggs <simon@2ndquadrant.com> wrote: > Make fast promotion the default promotion mode. > Continue to allow a request for synchronous > checkpoints as a mechanism in case of problems. Is there clean way to request synchronous checkpoint at the standby promotion? I'm sure that we can do that by creating the file "promote" and sending the SIGUSR1 signal to the postmaster. Or by using previous version of pg_ctl. These are not clean and would confuse users. Regards, -- Fujii Masao
On 1 May 2013 11:25, Fujii Masao <masao.fujii@gmail.com> wrote: > On Wed, Apr 24, 2013 at 8:49 PM, Simon Riggs <simon@2ndquadrant.com> wrote: >> Make fast promotion the default promotion mode. >> Continue to allow a request for synchronous >> checkpoints as a mechanism in case of problems. > > Is there clean way to request synchronous checkpoint at the standby promotion? > I'm sure that we can do that by creating the file "promote" and > sending the SIGUSR1 > signal to the postmaster. Or by using previous version of pg_ctl. > These are not clean > and would confuse users. I just removed the user interface at Heikki's request, so yes, I can see its not ideal interface. My wish was to have a mechanism should we need it. A third option would be to not have any way at all. What is your preference? --Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
On Wed, May 1, 2013 at 9:20 PM, Simon Riggs <simon@2ndquadrant.com> wrote: > On 1 May 2013 11:25, Fujii Masao <masao.fujii@gmail.com> wrote: >> On Wed, Apr 24, 2013 at 8:49 PM, Simon Riggs <simon@2ndquadrant.com> wrote: >>> Make fast promotion the default promotion mode. >>> Continue to allow a request for synchronous >>> checkpoints as a mechanism in case of problems. >> >> Is there clean way to request synchronous checkpoint at the standby promotion? >> I'm sure that we can do that by creating the file "promote" and >> sending the SIGUSR1 >> signal to the postmaster. Or by using previous version of pg_ctl. >> These are not clean >> and would confuse users. > > I just removed the user interface at Heikki's request, so yes, I can > see its not ideal interface. > > My wish was to have a mechanism should we need it. > > A third option would be to not have any way at all. > > What is your preference? My preference is adding something like --full-checkpoint option into pg_ctl promote. As far as I understand Heikki's request correctly, he dislikes the approach reusing -m option in pg_ctl promote. That is, previous behavior of the promotion is not "smarter" than current one, but we have to have specified "-m smart" to choose the previous behavior of the promotion. ISTM that his this request makes sense. So I'd like to propose to add new option which would not confuse users, into pg_ctl promote. Regards, -- Fujii Masao
On 1 May 2013 14:55, Fujii Masao <masao.fujii@gmail.com> wrote: > On Wed, May 1, 2013 at 9:20 PM, Simon Riggs <simon@2ndquadrant.com> wrote: >> On 1 May 2013 11:25, Fujii Masao <masao.fujii@gmail.com> wrote: >>> On Wed, Apr 24, 2013 at 8:49 PM, Simon Riggs <simon@2ndquadrant.com> wrote: >>>> Make fast promotion the default promotion mode. >>>> Continue to allow a request for synchronous >>>> checkpoints as a mechanism in case of problems. >>> >>> Is there clean way to request synchronous checkpoint at the standby promotion? >>> I'm sure that we can do that by creating the file "promote" and >>> sending the SIGUSR1 >>> signal to the postmaster. Or by using previous version of pg_ctl. >>> These are not clean >>> and would confuse users. >> >> I just removed the user interface at Heikki's request, so yes, I can >> see its not ideal interface. >> >> My wish was to have a mechanism should we need it. >> >> A third option would be to not have any way at all. >> >> What is your preference? > > My preference is adding something like --full-checkpoint option into > pg_ctl promote. > > As far as I understand Heikki's request correctly, he dislikes the > approach reusing > -m option in pg_ctl promote. That is, previous behavior of the promotion is not > "smarter" than current one, but we have to have specified "-m smart" to choose > the previous behavior of the promotion. ISTM that his this request makes sense. > > So I'd like to propose to add new option which would not confuse > users, into pg_ctl > promote. Heikki said "...remove pg_ctl -m fast/smart option altogether. There is no need to expose that to users." So it is no longer exposed to users. If there are others that share that opinion we may change this. --Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
On Wed, May 1, 2013 at 12:10 PM, Simon Riggs <simon@2ndquadrant.com> wrote: > Heikki said "...remove pg_ctl -m fast/smart option altogether. There > is no need to expose that to users." > > So it is no longer exposed to users. If there are others that share > that opinion we may change this. /me blinks. I'm not sure we truly need two types of promotion. But if we do, it makes no sense to me to have it and not allow users to select the one they want. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Wed, May 1, 2013 at 07:23:33PM -0400, Robert Haas wrote: > On Wed, May 1, 2013 at 12:10 PM, Simon Riggs <simon@2ndquadrant.com> wrote: > > Heikki said "...remove pg_ctl -m fast/smart option altogether. There > > is no need to expose that to users." > > > > So it is no longer exposed to users. If there are others that share > > that opinion we may change this. > > /me blinks. > > I'm not sure we truly need two types of promotion. But if we do, it > makes no sense to me to have it and not allow users to select the one > they want. I am also confused why we would have two promotion modes. Either the default mode works, or it doesn't, and we fix it. If there is enough concern that fast promotion will not work, should we remove that ability? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Thu, May 2, 2013 at 9:25 AM, Bruce Momjian <bruce@momjian.us> wrote: > On Wed, May 1, 2013 at 07:23:33PM -0400, Robert Haas wrote: >> On Wed, May 1, 2013 at 12:10 PM, Simon Riggs <simon@2ndquadrant.com> wrote: >> > Heikki said "...remove pg_ctl -m fast/smart option altogether. There >> > is no need to expose that to users." >> > >> > So it is no longer exposed to users. If there are others that share >> > that opinion we may change this. >> >> /me blinks. >> >> I'm not sure we truly need two types of promotion. But if we do, it >> makes no sense to me to have it and not allow users to select the one >> they want. > > I am also confused why we would have two promotion modes. Either the > default mode works, or it doesn't, and we fix it. If there is enough > concern that fast promotion will not work, should we remove that > ability? I don't have any other reason than that fast promotion is less stable. I agree that we should spend the time testing the feature rather than adding the workaround in this case. Regards, -- Fujii Masao