On Thu, Jan 14, 2021 at 1:55 AM Michael Paquier <mich...@paquier.xyz> wrote: > > On Wed, Jan 13, 2021 at 11:28:55PM +0900, Fujii Masao wrote: > > On Wed, Jan 13, 2021 at 10:51 PM John Naylor < john.nay...@enterprisedb.com> wrote: > >> It is strange, now that I think about it. My thinking was that the > >> former wording of "replication timeout" was a less literal > >> reference to the replication_timeout parameter, so I did the same > >> for wal_sender_timeout. A quick look shows we are not consistent > >> in the documentation as far as walsender vs. WAL sender. For the > >> purpose of the patch I agree it should be consistent within a > >> single message. Maybe the parameter should be spelled exactly as > >> is, with underscores? > > > > I'm ok with that. But there seems no other timeout messages using > > the parameter name. > > Could it be that nothing needs to change here because this refers to > timeouts with the replication protocol? The current state of things > on HEAD does not sound completely incorrect to me either.
It was off enough to cause brief confusion during a customer emergency. To show a bit more context around one of the proposed corrections: timeout = TimestampTzPlusMilliseconds(last_reply_timestamp, wal_sender_timeout); if (wal_sender_timeout > 0 && last_processing >= timeout) { /* * Since typically expiration of replication timeout means * communication problem, we don't send the error message to the * standby. */ ereport(COMMERROR, (errmsg("terminating walsender process due to replication timeout"))); My reading is, this is a case where the message didn't keep up with the change in parameter name. -- John Naylor EDB: http://www.enterprisedb.com