little mistakes in HS/SR
Hi,
I found some little mistakes in HS/SR code and document.
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 9ae022a..db78b2b 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -2000,7 +2000,7 @@ SET ENABLE_SEQSCAN TO OFF;
<varname>max_standby_archive_delay</> applies when WAL data is
being read from WAL archive (and is therefore not current).
The default is 30 seconds. Units are milliseconds if not specified.
- A value of -1 allows the standby to wait forever for conflicting
+ A value of <literal>-1</> allows the standby to wait forever
for conflicting
queries to complete.
This parameter can only be set in the <filename>postgresql.conf</>
file or on the server command line.
@@ -2030,7 +2030,7 @@ SET ENABLE_SEQSCAN TO OFF;
<varname>max_standby_streaming_delay</> applies when WAL data is
being received via streaming replication.
The default is 30 seconds. Units are milliseconds if not specified.
- A value of -1 allows the standby to wait forever for conflicting
+ A value of <literal>-1</> allows the standby to wait forever
for conflicting
queries to complete.
This parameter can only be set in the <filename>postgresql.conf</>
file or on the server command line.We should enclose -1 with <literal> tag.
diff --git a/src/backend/replication/walsender.c
b/src/backend/replication/walsender.c
index 0c4b217..53c2581 100644
--- a/src/backend/replication/walsender.c
+++ b/src/backend/replication/walsender.c
@@ -93,6 +93,7 @@ static volatile sig_atomic_t ready_to_stop = false;
static void WalSndSigHupHandler(SIGNAL_ARGS);
static void WalSndShutdownHandler(SIGNAL_ARGS);
static void WalSndQuickDieHandler(SIGNAL_ARGS);
+static void WalSndLastCycleHandler(SIGNAL_ARGS);We seems to have forgotten to add the declaration of WalSndLastCycleHandler().
I also attached the context-diff patch.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
Attachments:
fix_mistakes_hs_sr_v1.patchapplication/octet-stream; name=fix_mistakes_hs_sr_v1.patchDownload+5-4
On Thu, Jul 22, 2010 at 1:41 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
We should enclose -1 with <literal> tag.
A quick survey of the documentation as a whole suggests that we
enclose -1 with <literal> in a few places but more commonly we don't.
I have no position on whether we should do it or not, but maybe we
should try to be consistent throughout the docs? Or at least have a
consistent rule for deciding what to do in a particular case?
We seems to have forgotten to add the declaration of WalSndLastCycleHandler().
I've committed this part.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
Robert Haas wrote:
On Thu, Jul 22, 2010 at 1:41 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
We should enclose -1 with <literal> tag.
A quick survey of the documentation as a whole suggests that we
enclose -1 with <literal> in a few places but more commonly we don't.
I have no position on whether we should do it or not, but maybe we
should try to be consistent throughout the docs? Or at least have a
consistent rule for deciding what to do in a particular case?
Excellent question. I went through the documentation and removed
<literal> tags where appropriate --- there are cases where we are
referencing an actual number, and there <literal> makes sense. Applied
patch attached.
I think the larger question is whether we should say "zero" for 0 and
"one" for 1, etc. Prose typography suggests we should, but for
technical manuals, I am not sure. Ideas?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
Attachments:
/rtmp/number.difftext/x-diffDownload+21-23
On Sun, Feb 6, 2011 at 6:44 PM, Bruce Momjian <bruce@momjian.us> wrote:
Robert Haas wrote:
On Thu, Jul 22, 2010 at 1:41 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
We should enclose -1 with <literal> tag.
A quick survey of the documentation as a whole suggests that we
enclose -1 with <literal> in a few places but more commonly we don't.
I have no position on whether we should do it or not, but maybe we
should try to be consistent throughout the docs? Or at least have a
consistent rule for deciding what to do in a particular case?Excellent question. I went through the documentation and removed
<literal> tags where appropriate --- there are cases where we are
referencing an actual number, and there <literal> makes sense. Applied
patch attached.I think the larger question is whether we should say "zero" for 0 and
"one" for 1, etc. Prose typography suggests we should, but for
technical manuals, I am not sure. Ideas?
I am doubtful that this makes sense in general. I suspect it depends
somewhat on context.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Robert Haas wrote:
On Sun, Feb 6, 2011 at 6:44 PM, Bruce Momjian <bruce@momjian.us> wrote:
Robert Haas wrote:
On Thu, Jul 22, 2010 at 1:41 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
We should enclose -1 with <literal> tag.
A quick survey of the documentation as a whole suggests that we
enclose -1 with <literal> in a few places but more commonly we don't.
I have no position on whether we should do it or not, but maybe we
should try to be consistent throughout the docs? ?Or at least have a
consistent rule for deciding what to do in a particular case?Excellent question. ?I went through the documentation and removed
<literal> tags where appropriate --- there are cases where we are
referencing an actual number, and there <literal> makes sense. ?Applied
patch attached.I think the larger question is whether we should say "zero" for 0 and
"one" for 1, etc. ?Prose typography suggests we should, but for
technical manuals, I am not sure. ?Ideas?I am doubtful that this makes sense in general. I suspect it depends
somewhat on context.
We do spell out "zero" in a few cases where it makes sense, so it seems
we need no change here.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +