On Thu, Jan 14, 2021 at 1:55 AM Michael Paquier 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
On Wed, Jan 13, 2021 at 11:28:55PM +0900, Fujii Masao wrote:
> On Wed, Jan 13, 2021 at 10:51 PM John Naylor
> 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
On Wed, Jan 13, 2021 at 10:51 PM John Naylor
wrote:
>
>
> On Tue, Jan 12, 2021 at 9:37 PM Fujii Masao wrote:
> >
> > Thanks for the patch! I think this change makes sense.
> >
> > - (errmsg("terminating walsender process
> > due to replication timeout")));
> > +
On Tue, Jan 12, 2021 at 9:37 PM Fujii Masao wrote:
>
> Thanks for the patch! I think this change makes sense.
>
> - (errmsg("terminating walsender process
> due to replication timeout")));
> + (errmsg("terminating walsender process
> due
On Wed, Jan 13, 2021 at 5:39 AM John Naylor
wrote:
>
> Hi,
>
> The parameter replication_timeout was retired in commit 6f60fdd701 back in
> 2012, but some comments and error messages seem to refer to that old setting
> instead of wal_sender_timeout or wal_receiver_timeout. The attached patch
>
Hi,
The parameter replication_timeout was retired in commit 6f60fdd701 back in
2012, but some comments and error messages seem to refer to that old
setting instead of wal_sender_timeout or wal_receiver_timeout. The attached
patch replaces the old language with more specific references.
--
John
