Re: 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

On Thu, Jul 22, 2010 at 1:41 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)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(dot)fujii(at)gmail(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

On Sun, Feb 6, 2011 at 6:44 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Robert Haas wrote:
>> On Thu, Jul 22, 2010 at 1:41 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)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(at)momjian(dot)us> wrote:
> > Robert Haas wrote:
> >> On Thu, Jul 22, 2010 at 1:41 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +