Re: [HACKERS] Minor typo in syncrep.c

2016-02-29 Thread Alvaro Herrera
Amit Langote wrote:
> On 2016/02/03 17:50, Amit Langote wrote:
> > Attached patch removes an extraneous word in the comment above
> 
> I kept reading and found one place in a comment within the function where
> a word is most probably missing,  Attached fixes it.

Pushed both, thanks.

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, 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


Re: [HACKERS] Minor typo in syncrep.c

2016-02-03 Thread Amit Langote
On 2016/02/03 17:50, Amit Langote wrote:
> Attached patch removes an extraneous word in the comment above

I kept reading and found one place in a comment within the function where
a word is most probably missing,  Attached fixes it.

 /*
  * If this WALSender is serving a standby that is not on the list of
- * potential standbys then we have nothing to do. If we are still
starting
- * up, still running base backup or the current flush position is still
- * invalid, then leave quickly also.
+ * potential sync standbys then we have nothing to do. If we are still
+ * starting up, still running base backup or the current flush position
+ * is still invalid, then leave quickly also.

Thanks,
Amit
diff --git a/src/backend/replication/syncrep.c b/src/backend/replication/syncrep.c
index 7f85b88..c44161b 100644
--- a/src/backend/replication/syncrep.c
+++ b/src/backend/replication/syncrep.c
@@ -419,9 +419,9 @@ SyncRepReleaseWaiters(void)
 
 	/*
 	 * If this WALSender is serving a standby that is not on the list of
-	 * potential standbys then we have nothing to do. If we are still starting
-	 * up, still running base backup or the current flush position is still
-	 * invalid, then leave quickly also.
+	 * potential sync standbys then we have nothing to do. If we are still
+	 * starting up, still running base backup or the current flush position
+	 * is still invalid, then leave quickly also.
 	 */
 	if (MyWalSnd->sync_standby_priority == 0 ||
 		MyWalSnd->state < WALSNDSTATE_STREAMING ||

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] A typo in syncrep.c

2015-12-22 Thread Robert Haas
On Tue, Dec 22, 2015 at 3:18 AM, Kyotaro HORIGUCHI
 wrote:
> Thank you Robert and sorry for bothering you with a silly question!
>
> I understand what I did clearly thanks to your attentive indication.
>
> At Mon, 21 Dec 2015 07:50:40 -0500, Robert Haas  wrote 
> in 
>> >> >> + * lead the client to believe that the transaction is aborted, which
>> >> No, that's correct the way it is.  What you're proposing wouldn't
>> >> exactly be wrong, but it's a little less clear and direct.
>> >
>> > Hmm. I thought they are equal in meaning and make clearer, but I
>> > understand they have such difference. Thank you for correcting
>> > it.
>>
>> The difference is that if you say "the transaction aborted" you mean
>> that the transaction did something - specifically, it aborted.  If you
>> say that "the transaction is aborted" you are talking about the state
>> in which the transaction ended up, without really saying how it got
>> that way.
>
> What I made here was a mistake of the word class of the
> "transaction" by somehow omitting the "that" in the original
> sentense. It is not the objective case as in the case where the
> "that" is omitted, but the subjective case there. Then the
> "aborted" is not the objective complement but the past tense. The
> "that" had been returned in my mind before I knew it but, after
> all, adding "is" there utterly changes the maning as you pointed
> out.

Actually, you might be surprised to hear that you can omit the word
"that" here without changing the meaning.  I tend to avoid that in
formal writing for clarity but the word isn't technically necessary.

>>  In this case we are talking about whether the client might
>> think that the transaction did something (aborted), not what the
>> client might think about the state we ended up in (aborted), so the
>> current wording seems better to me.
>
> I understand that you're completely right. Sorry for my silly
> mistake.

It's not a silly mistake.  And I do appreciate you taking the time to proofread.

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


Re: [HACKERS] A typo in syncrep.c

2015-12-22 Thread Kyotaro HORIGUCHI
Thank you Robert and sorry for bothering you with a silly question!

I understand what I did clearly thanks to your attentive indication.

At Mon, 21 Dec 2015 07:50:40 -0500, Robert Haas  wrote 
in 
> >> >> + * lead the client to believe that the transaction is aborted, which
> >> No, that's correct the way it is.  What you're proposing wouldn't
> >> exactly be wrong, but it's a little less clear and direct.
> >
> > Hmm. I thought they are equal in meaning and make clearer, but I
> > understand they have such difference. Thank you for correcting
> > it.
> 
> The difference is that if you say "the transaction aborted" you mean
> that the transaction did something - specifically, it aborted.  If you
> say that "the transaction is aborted" you are talking about the state
> in which the transaction ended up, without really saying how it got
> that way.

What I made here was a mistake of the word class of the
"transaction" by somehow omitting the "that" in the original
sentense. It is not the objective case as in the case where the
"that" is omitted, but the subjective case there. Then the
"aborted" is not the objective complement but the past tense. The
"that" had been returned in my mind before I knew it but, after
all, adding "is" there utterly changes the maning as you pointed
out.

>  In this case we are talking about whether the client might
> think that the transaction did something (aborted), not what the
> client might think about the state we ended up in (aborted), so the
> current wording seems better to me.

I understand that you're completely right. Sorry for my silly
mistake.

regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center




-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] A typo in syncrep.c

2015-12-21 Thread Robert Haas
On Mon, Dec 21, 2015 at 12:23 AM, Kyotaro HORIGUCHI
 wrote:
> At Fri, 18 Dec 2015 12:44:34 -0500, Robert Haas  wrote 
> in 
>> On Wed, Dec 16, 2015 at 3:33 AM, Kyotaro HORIGUCHI
>>  wrote:
>> > Hello, I think I found a typo in a comment of syncrep.c.
>> >
>> >>   * acknowledge the commit nor raise ERROR or FATAL.  The latter would
>> >> - * lead the client to believe that that the transaction aborted, which
>> >>   * is not true: it's already committed locally. The former is no good
>> >
>> > The 'that' looks duplicate.
>>
>> Agreed.
>>
>> > And it might be better to put a
>> > be-verb before the 'aborted'.
>> >
>> >> + * lead the client to believe that the transaction is aborted, which
>>
>> No, that's correct the way it is.  What you're proposing wouldn't
>> exactly be wrong, but it's a little less clear and direct.
>
> Hmm. I thought they are equal in meaning and make clearer, but I
> understand they have such difference. Thank you for correcting
> it.

The difference is that if you say "the transaction aborted" you mean
that the transaction did something - specifically, it aborted.  If you
say that "the transaction is aborted" you are talking about the state
in which the transaction ended up, without really saying how it got
that way.  In this case we are talking about whether the client might
think that the transaction did something (aborted), not what the
client might think about the state we ended up in (aborted), so the
current wording seems better to me.

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


Re: [HACKERS] A typo in syncrep.c

2015-12-20 Thread Kyotaro HORIGUCHI
Hello,

At Fri, 18 Dec 2015 12:44:34 -0500, Robert Haas  wrote 
in 
> On Wed, Dec 16, 2015 at 3:33 AM, Kyotaro HORIGUCHI
>  wrote:
> > Hello, I think I found a typo in a comment of syncrep.c.
> >
> >>   * acknowledge the commit nor raise ERROR or FATAL.  The latter would
> >> - * lead the client to believe that that the transaction aborted, which
> >>   * is not true: it's already committed locally. The former is no good
> >
> > The 'that' looks duplicate.
> 
> Agreed.
> 
> > And it might be better to put a
> > be-verb before the 'aborted'.
> >
> >> + * lead the client to believe that the transaction is aborted, which
> 
> No, that's correct the way it is.  What you're proposing wouldn't
> exactly be wrong, but it's a little less clear and direct.

Hmm. I thought they are equal in meaning and make clearer, but I
understand they have such difference. Thank you for correcting
it.

> Committed the part of your patch that removes the extra "that".

Thank you!

regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center




-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] A typo in syncrep.c

2015-12-18 Thread Robert Haas
On Wed, Dec 16, 2015 at 3:33 AM, Kyotaro HORIGUCHI
 wrote:
> Hello, I think I found a typo in a comment of syncrep.c.
>
>>   * acknowledge the commit nor raise ERROR or FATAL.  The latter would
>> - * lead the client to believe that that the transaction aborted, which
>>   * is not true: it's already committed locally. The former is no good
>
> The 'that' looks duplicate.

Agreed.

> And it might be better to put a
> be-verb before the 'aborted'.
>
>> + * lead the client to believe that the transaction is aborted, which

No, that's correct the way it is.  What you're proposing wouldn't
exactly be wrong, but it's a little less clear and direct.

Committed the part of your patch that removes the extra "that".

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