From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Michael Loftis <mloftis(at)wgops(dot)com> |
Cc: | Virendra Negi <viren(dot)negi(at)teliax(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Primary keepalive message not appearing in Logical Streaming Replication |
Date: | 2019-09-15 16:30:52 |
Message-ID: | CAMkU=1ySuxBMXZbLacpoL=EptTNcbdRCGHOWMDe+S-sX2vyvTQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Sep 15, 2019 at 11:44 AM Michael Loftis <mloftis(at)wgops(dot)com> wrote:
>
>
> On Sun, Sep 15, 2019 at 08:36 Virendra Negi <viren(dot)negi(at)teliax(dot)com> wrote:
>
>> Oh I miss the documentation link there you go
>> https://www.postgresql.org/docs/9.5/protocol-replication.html
>>
>> On Sun, Sep 15, 2019 at 8:05 PM Virendra Negi <viren(dot)negi(at)teliax(dot)com>
>> wrote:
>>
>>> Agreed but why is there a message specification for it describe in the
>>> documentation and it ask to client reply back if a particular *bit* is
>>> set.(1 means that the client should reply to this message as soon as
>>> possible, to avoid a timeout disconnect. 0 otherwise)
>>>
>>
> This is unrelated to TCP keepalive. I honestly don't know where the knob
> is to turn these on but the configuration variables you quoted earlier I am
> familiar with and they are not it. Perhaps someone else can chime in with
> how to enable the protocol level keepalive in replication.
>
Protocol-level keepalives are governed by "wal_sender_timeout"
Cheers,
Jeff
From | Date | Subject | |
---|---|---|---|
Next Message | Kuntal Ghosh | 2019-09-15 17:26:48 | Re: POC: Cleaning up orphaned files using undo logs |
Previous Message | Jeff Janes | 2019-09-15 16:20:28 | Re: log spam with postgres_fdw |