On Thur, Apr 14, 2022 at 8:21 PM Euler Taveira <eu...@eulerto.com> wrote: > Thanks for your comments.
> + * For a large transaction, if we don't send any change to the downstream > for a > + * long time then it can timeout. This can happen when all or most of the > + * changes are either not published or got filtered out. > > We should probable mention that "long time" is wal_receiver_timeout on > subscriber. Improve as suggested. Add "(exceeds the wal_receiver_timeout of standby)" to explain what "long time" means. > + * change as that can have overhead. Testing reveals that there is no > + * noticeable overhead in doing it after continuously processing 100 or so > + * changes. > > Tests revealed that ... Improve as suggested. > + * We don't have a mechanism to get the ack for any LSN other than end > xact > + * lsn from the downstream. So, we track lag only for end xact lsn's. > > s/lsn/LSN/ and s/lsn's/LSNs/ > > I would say "end of transaction LSN". Improve as suggested. > + * If too many changes are processed then try to send a keepalive message to > + * receiver to avoid timeouts. > > In logical replication, if too many changes are processed then try to send a > keepalive message. It might avoid a timeout in the subscriber. Improve as suggested. Kindly have a look at new patch shared in [1]. [1] - https://www.postgresql.org/message-id/OS3PR01MB627561344A2C7ECF68E41D7E9EF39%40OS3PR01MB6275.jpnprd01.prod.outlook.com Regards, Wang wei
