pgsql: Make fast promotion the default promotion mode.
Make fast promotion the default promotion mode.
Continue to allow a request for synchronous
checkpoints as a mechanism in case of problems.
Branch
------
master
Details
-------
http://git.postgresql.org/pg/commitdiff/2317a63328cd9d1c22d02218c6959f340b63d98f
Modified Files
--------------
src/backend/access/transam/xlog.c | 15 ++-------------
src/bin/pg_ctl/pg_ctl.c | 17 ++++++-----------
2 files changed, 8 insertions(+), 24 deletions(-)
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers