Sync rep doc corrections
I've attached a small patch with a bit of clarification and a typo fix
in the synchronous_standby_names parameter info.
--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935
Attachments:
sync_rep_doc_fix.patchapplication/octet-stream; name=sync_rep_doc_fix.patchDownload
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 822ef4b..f2fbe05 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -2072,8 +2072,9 @@ SET ENABLE_SEQSCAN TO OFF;
synchronous standby that will wake sleeping users following commit.
The synchronous standby will be the first named standby that is
both currently connected and streaming in real-time to the standby
- (as shown by a state of "STREAMING"). Other standby servers
- with listed later will become potential synchronous standbys.
+ (as shown by a state of "STREAMING" visible in the sync_state column
+ of the pg_stat_replication view). Other standby servers
+ subsequently listed will become potential synchronous standbys.
If the current synchronous standby disconnects for whatever reason
it will be replaced immediately with the next highest priority standby.
Specifying more than one standby name can allow very high availability.
@@ -2092,7 +2093,7 @@ SET ENABLE_SEQSCAN TO OFF;
</para>
<para>
If a standby is removed from the list of servers then it will stop
- being the synchronous standby, allowing another to take it's place.
+ being the synchronous standby, allowing another to take its place.
If the list is empty, synchronous replication will not be
possible, whatever the setting of <varname>synchronous_replication</>,
however, already waiting commits will continue to wait.
On 7 March 2011 15:27, Thom Brown <thom@linux.com> wrote:
I've attached a small patch with a bit of clarification and a typo fix
in the synchronous_standby_names parameter info.
Okay, I've noticed that the main documentation also needed some fixes,
so those have been included in this new patch.
--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935
Attachments:
sync_rep_doc_fix.v2.patchapplication/octet-stream; name=sync_rep_doc_fix.v2.patchDownload
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 822ef4b..f2fbe05 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -2072,8 +2072,9 @@ SET ENABLE_SEQSCAN TO OFF;
synchronous standby that will wake sleeping users following commit.
The synchronous standby will be the first named standby that is
both currently connected and streaming in real-time to the standby
- (as shown by a state of "STREAMING"). Other standby servers
- with listed later will become potential synchronous standbys.
+ (as shown by a state of "STREAMING" visible in the sync_state column
+ of the pg_stat_replication view). Other standby servers
+ subsequently listed will become potential synchronous standbys.
If the current synchronous standby disconnects for whatever reason
it will be replaced immediately with the next highest priority standby.
Specifying more than one standby name can allow very high availability.
@@ -2092,7 +2093,7 @@ SET ENABLE_SEQSCAN TO OFF;
</para>
<para>
If a standby is removed from the list of servers then it will stop
- being the synchronous standby, allowing another to take it's place.
+ being the synchronous standby, allowing another to take its place.
If the list is empty, synchronous replication will not be
possible, whatever the setting of <varname>synchronous_replication</>,
however, already waiting commits will continue to wait.
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index e30552f..e33d315 100644
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -927,7 +927,7 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
<para>
All parameters have useful default values, so we can enable
- synchronous replication easily just by setting this on the primary
+ synchronous replication easily just by setting this on the primary:
<programlisting>
synchronous_replication = on
@@ -938,7 +938,7 @@ synchronous_replication = on
even if that takes a very long time.
<varname>synchronous_replication</> can be set by individual
users, so can be configured in the configuration file, for particular
- users or databases, or dynamically by applications programs.
+ users or databases, or dynamically by applications.
</para>
<para>
@@ -1008,9 +1008,6 @@ synchronous_replication = on
<para>
You should consider that the network bandwidth must be higher than
the rate of generation of WAL data.
- 10% of changes are important customer details, while
- 90% of changes are less important data that the business can more
- easily survive if it is lost, such as chat messages between users.
</para>
</sect3>
@@ -1019,7 +1016,7 @@ synchronous_replication = on
<title>Planning for High Availability</title>
<para>
- Commits made when synchronous_replication is set will wait until at
+ Commits made when synchronous_replication is set will wait until
the sync standby responds. The response may never occur if the last,
or only, standby should crash.
</para>
On Mon, Mar 7, 2011 at 6:16 AM, Thom Brown <thom@linux.com> wrote:
On 7 March 2011 15:27, Thom Brown <thom@linux.com> wrote:
I've attached a small patch with a bit of clarification and a typo fix
in the synchronous_standby_names parameter info.Okay, I've noticed that the main documentation also needed some fixes,
so those have been included in this new patch.
I don't think it's necessary to cross-post these emails....
I've applied all of this but the first hunk, which I don't believe to
be correct.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On 7 March 2011 22:31, Robert Haas <robertmhaas@gmail.com> wrote:
On Mon, Mar 7, 2011 at 6:16 AM, Thom Brown <thom@linux.com> wrote:
On 7 March 2011 15:27, Thom Brown <thom@linux.com> wrote:
I've attached a small patch with a bit of clarification and a typo fix
in the synchronous_standby_names parameter info.Okay, I've noticed that the main documentation also needed some fixes,
so those have been included in this new patch.I don't think it's necessary to cross-post these emails....
I've received conflicting information in the past on this, but I'm
assuming you're suggesting to send this just to the -docs list in
future?
--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935
On Mon, Mar 07, 2011 at 10:53:17PM +0530, Thom Brown wrote:
On 7 March 2011 22:31, Robert Haas <robertmhaas@gmail.com> wrote:
On Mon, Mar 7, 2011 at 6:16 AM, Thom Brown <thom@linux.com> wrote:
On 7 March 2011 15:27, Thom Brown <thom@linux.com> wrote:
I've attached a small patch with a bit of clarification and a typo fix
in the synchronous_standby_names parameter info.Okay, I've noticed that the main documentation also needed some fixes,
so those have been included in this new patch.I don't think it's necessary to cross-post these emails....
I've received conflicting information in the past on this, but I'm
assuming you're suggesting to send this just to the -docs list in
future?
As I'm putting together the patches section for the PostgreSQL Weekly
News, it helps me *enormously* to have only one list I need to check,
so at least for me, it's an enormous help to have all patches at least
CC'd, or better still, only posted, to -hackers.
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
On 7 March 2011 23:21, David Fetter <david@fetter.org> wrote:
On Mon, Mar 07, 2011 at 10:53:17PM +0530, Thom Brown wrote:
On 7 March 2011 22:31, Robert Haas <robertmhaas@gmail.com> wrote:
On Mon, Mar 7, 2011 at 6:16 AM, Thom Brown <thom@linux.com> wrote:
On 7 March 2011 15:27, Thom Brown <thom@linux.com> wrote:
I've attached a small patch with a bit of clarification and a typo fix
in the synchronous_standby_names parameter info.Okay, I've noticed that the main documentation also needed some fixes,
so those have been included in this new patch.I don't think it's necessary to cross-post these emails....
I've received conflicting information in the past on this, but I'm
assuming you're suggesting to send this just to the -docs list in
future?As I'm putting together the patches section for the PostgreSQL Weekly
News, it helps me *enormously* to have only one list I need to check,
so at least for me, it's an enormous help to have all patches at least
CC'd, or better still, only posted, to -hackers.
I cross-posted as it's a docs change, but I want to invite the
critical eye of those who dev'd it. Okay, so doc patches should go
exclusively to the -hackers list? Last time I recall some disparity
surrounding what I should be doing.
--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935
On Mon, Mar 07, 2011 at 11:34:48PM +0530, Thom Brown wrote:
On 7 March 2011 23:21, David Fetter <david@fetter.org> wrote:
On Mon, Mar 07, 2011 at 10:53:17PM +0530, Thom Brown wrote:
On 7 March 2011 22:31, Robert Haas <robertmhaas@gmail.com> wrote:
On Mon, Mar 7, 2011 at 6:16 AM, Thom Brown <thom@linux.com> wrote:
On 7 March 2011 15:27, Thom Brown <thom@linux.com> wrote:
I've attached a small patch with a bit of clarification and a typo fix
in the synchronous_standby_names parameter info.Okay, I've noticed that the main documentation also needed some fixes,
so those have been included in this new patch.I don't think it's necessary to cross-post these emails....
I've received conflicting information in the past on this, but I'm
assuming you're suggesting to send this just to the -docs list in
future?As I'm putting together the patches section for the PostgreSQL Weekly
News, it helps me *enormously* to have only one list I need to check,
so at least for me, it's an enormous help to have all patches at least
CC'd, or better still, only posted, to -hackers.I cross-posted as it's a docs change, but I want to invite the
critical eye of those who dev'd it. Okay, so doc patches should go
exclusively to the -hackers list? Last time I recall some disparity
surrounding what I should be doing.
"Should" is a word I won't get into on this subject. I was expressing
and justifying a personal preference :)
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
On Mon, Mar 7, 2011 at 1:04 PM, Thom Brown <thom@linux.com> wrote:
On 7 March 2011 23:21, David Fetter <david@fetter.org> wrote:
On Mon, Mar 07, 2011 at 10:53:17PM +0530, Thom Brown wrote:
On 7 March 2011 22:31, Robert Haas <robertmhaas@gmail.com> wrote:
On Mon, Mar 7, 2011 at 6:16 AM, Thom Brown <thom@linux.com> wrote:
On 7 March 2011 15:27, Thom Brown <thom@linux.com> wrote:
I've attached a small patch with a bit of clarification and a typo fix
in the synchronous_standby_names parameter info.Okay, I've noticed that the main documentation also needed some fixes,
so those have been included in this new patch.I don't think it's necessary to cross-post these emails....
I've received conflicting information in the past on this, but I'm
assuming you're suggesting to send this just to the -docs list in
future?As I'm putting together the patches section for the PostgreSQL Weekly
News, it helps me *enormously* to have only one list I need to check,
so at least for me, it's an enormous help to have all patches at least
CC'd, or better still, only posted, to -hackers.I cross-posted as it's a docs change, but I want to invite the
critical eye of those who dev'd it. Okay, so doc patches should go
exclusively to the -hackers list? Last time I recall some disparity
surrounding what I should be doing.
I'm not sure we have any unanimity on what the "right" thing to do
here is, and I guess I don't *really* care, except that I mildly
dislike cross-posting as a general principle.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Thom Brown <thom@linux.com> writes:
On 7 March 2011 23:21, David Fetter <david@fetter.org> wrote:
As I'm putting together the patches section for the PostgreSQL Weekly
News, it helps me *enormously* to have only one list I need to check,
so at least for me, it's an enormous help to have all patches at least
CC'd, or better still, only posted, to -hackers.
I'm not certain that David's convenience should be the exclusive
consideration when deciding what goes where ;-)
I cross-posted as it's a docs change, but I want to invite the
critical eye of those who dev'd it. Okay, so doc patches should go
exclusively to the -hackers list? Last time I recall some disparity
surrounding what I should be doing.
If we do that then it becomes worth wondering what the -docs list is for
at all. Maybe we *should* get rid of it; I dunno. I see your point
about how the factual issues involved in a docs change ought to be
vetted on -hackers, but on the other hand the traffic on -hackers is so
high already that I'm not happy about folding another list with a
reasonably distinct charter into it.
regards, tom lane
Excerpts from Tom Lane's message of lun mar 07 15:16:31 -0300 2011:
If we do that then it becomes worth wondering what the -docs list is for
at all. Maybe we *should* get rid of it; I dunno. I see your point
about how the factual issues involved in a docs change ought to be
vetted on -hackers, but on the other hand the traffic on -hackers is so
high already that I'm not happy about folding another list with a
reasonably distinct charter into it.
Searching for doc changes/suggestions is helped tremendously by having
them in a separate list. -1 for merging it with -hackers. I have no
opinion on the -hackers crossposting issue as it doesn't affect me at
all.
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On Mon, Mar 07, 2011 at 03:45:17PM -0300, Alvaro Herrera wrote:
Excerpts from Tom Lane's message of lun mar 07 15:16:31 -0300 2011:
If we do that then it becomes worth wondering what the -docs list is for
at all. Maybe we *should* get rid of it; I dunno. I see your point
about how the factual issues involved in a docs change ought to be
vetted on -hackers, but on the other hand the traffic on -hackers is so
high already that I'm not happy about folding another list with a
reasonably distinct charter into it.Searching for doc changes/suggestions is helped tremendously by having
them in a separate list. -1 for merging it with -hackers. I have no
opinion on the -hackers crossposting issue as it doesn't affect me at
all.
Definitely don't merge. Crossposting, I think, should be reserved for
significant factual changes to docs of features that are in current
development, like ... syncrep. :-) Basically, keep docs work on docs,
but cross-post to hackers when a cross-check is needed. Don't routinely
crosspost, lest that train hackers to ignore the docs posts. After all,
we insist that developers of patches submit docs: correct documentation
is a valid concern for all developers.
Ross
P.S. Everyone is aware of the settings for majordomo, so you only get
one of any crosspost, right?
--
Ross Reedstrom, Ph.D. reedstrm@rice.edu
Systems Engineer & Admin, Research Scientist phone: 713-348-6166
Connexions http://cnx.org fax: 713-348-3665
Rice University MS-375, Houston, TX 77005
GPG Key fingerprint = F023 82C8 9B0E 2CC6 0D8E F888 D3AE 810E 88F0 BEDE
On Mon, Mar 07, 2011 at 01:01:05PM -0600, Ross J. Reedstrom wrote:
On Mon, Mar 07, 2011 at 03:45:17PM -0300, Alvaro Herrera wrote:
Excerpts from Tom Lane's message of lun mar 07 15:16:31 -0300
2011:If we do that then it becomes worth wondering what the -docs
list is for at all. Maybe we *should* get rid of it; I dunno.
I see your point about how the factual issues involved in a docs
change ought to be vetted on -hackers, but on the other hand the
traffic on -hackers is so high already that I'm not happy about
folding another list with a reasonably distinct charter into it.Searching for doc changes/suggestions is helped tremendously by
having them in a separate list. -1 for merging it with -hackers.
I have no opinion on the -hackers crossposting issue as it doesn't
affect me at all.Definitely don't merge. Crossposting, I think, should be reserved
for significant factual changes to docs of features that are in
current development, like ... syncrep. :-) Basically, keep docs work
on docs, but cross-post to hackers when a cross-check is needed.
Don't routinely crosspost, lest that train hackers to ignore the
docs posts. After all, we insist that developers of patches submit
docs: correct documentation is a valid concern for all developers.Ross P.S. Everyone is aware of the settings for majordomo, so you
only get one of any crosspost, right?
It's not that simple. If it were, I wouldn't have been asking for
this in the first place.
Re: docs, I'd actually like to see that list gone, as the separation
of docs from code is one that's actively unhelpful. We don't have a
separate "docs" team, and we rightly put the responsibility of
documenting changes on the person or people patching them in.
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
On 3/7/11 11:07 AM, David Fetter wrote:
Re: docs, I'd actually like to see that list gone, as the separation
of docs from code is one that's actively unhelpful. We don't have a
separate "docs" team, and we rightly put the responsibility of
documenting changes on the person or people patching them in.
The -hackers list has enough traffic as it is.
And if we don't have docs contributors who aren't code contributors (and
I think we do), then that's a problem to be solved, not casually accepted.
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
On Mon, Mar 7, 2011 at 2:07 PM, David Fetter <david@fetter.org> wrote:
Re: docs, I'd actually like to see that list gone, as the separation
of docs from code is one that's actively unhelpful. We don't have a
separate "docs" team, and we rightly put the responsibility of
documenting changes on the person or people patching them in.
You're in the minority on this one.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Mon, Mar 07, 2011 at 02:31:18PM -0500, Robert Haas wrote:
On Mon, Mar 7, 2011 at 2:07 PM, David Fetter <david@fetter.org> wrote:
Re: docs, I'd actually like to see that list gone, as the separation
of docs from code is one that's actively unhelpful. �We don't have a
separate "docs" team, and we rightly put the responsibility of
documenting changes on the person or people patching them in.You're in the minority on this one.
It happens, but I keep speaking up anyhow. Minority status isn't
always permanent. :)
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
On 8 March 2011 01:08, David Fetter <david@fetter.org> wrote:
On Mon, Mar 07, 2011 at 02:31:18PM -0500, Robert Haas wrote:
On Mon, Mar 7, 2011 at 2:07 PM, David Fetter <david@fetter.org> wrote:
Re: docs, I'd actually like to see that list gone, as the separation
of docs from code is one that's actively unhelpful. We don't have a
separate "docs" team, and we rightly put the responsibility of
documenting changes on the person or people patching them in.You're in the minority on this one.
It happens, but I keep speaking up anyhow. Minority status isn't
always permanent. :)
Okay, to avoid any -hackers list noise, I'll exclusively send them to
-docs in future, with the exception of replying to -committers or
-hackers when a commit/patch contains fail.
--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Thom Brown wrote:
On 7 March 2011 22:31, Robert Haas <robertmhaas@gmail.com> wrote:
On Mon, Mar 7, 2011 at 6:16 AM, Thom Brown <thom@linux.com> wrote:
On 7 March 2011 15:27, Thom Brown <thom@linux.com> wrote:
I've attached a small patch with a bit of clarification and a typo fix
in the synchronous_standby_names parameter info.Okay, I've noticed that the main documentation also needed some fixes,
so those have been included in this new patch.I don't think it's necessary to cross-post these emails....
I've received conflicting information in the past on this, but I'm
assuming you're suggesting to send this just to the -docs list in
future?
I send pure woring changes only to the docs list, and items that are
related to behavior and docs to both. Does that help?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
On Wed, Mar 9, 2011 at 11:43 PM, Bruce Momjian <bruce@momjian.us> wrote:
Thom Brown wrote:
On 7 March 2011 22:31, Robert Haas <robertmhaas@gmail.com> wrote:
On Mon, Mar 7, 2011 at 6:16 AM, Thom Brown <thom@linux.com> wrote:
On 7 March 2011 15:27, Thom Brown <thom@linux.com> wrote:
I've attached a small patch with a bit of clarification and a typo fix
in the synchronous_standby_names parameter info.Okay, I've noticed that the main documentation also needed some fixes,
so those have been included in this new patch.I don't think it's necessary to cross-post these emails....
I've received conflicting information in the past on this, but I'm
assuming you're suggesting to send this just to the -docs list in
future?I send pure woring changes only to the docs list, and items that are
related to behavior and docs to both. Does that help?
Well, there's basically no point in posting patches you've already
committed. We have a list where those get posted, and it's
-committers. If you're referring to patches you haven't committed
yet, then the effect of sending them to both -docs and -hackers is
presumably to encourage even fewer people to read and respond to
traffic on -docs than already do.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company