RE: Logical replication timeout problem
От | wangw.fnst@fujitsu.com |
---|---|
Тема | RE: Logical replication timeout problem |
Дата | |
Msg-id | OS3PR01MB6275F9B336AA1FEF4D33E9179EC99@OS3PR01MB6275.jpnprd01.prod.outlook.com обсуждение исходный текст |
Ответ на | Re: Logical replication timeout problem (Amit Kapila <amit.kapila16@gmail.com>) |
Список | pgsql-hackers |
On Mon, May 9, 2022 at 11:23 AM Amit Kapila <amit.kapila16@gmail.com> wrote: > On Mon, May 9, 2022 at 7:01 PM Euler Taveira <euler@eulerto.com> wrote: > > > > On Mon, May 9, 2022, at 3:47 AM, Amit Kapila wrote: > > > > Thanks. The patch LGTM. I'll push and back-patch this after the > > current minor release is done unless there are more comments related > > to this work. > > ...... > > Does this issue deserve a test? A small wal_receiver_timeout. Although, I'm > not > > sure how stable the test will be. > > > > Yes, the main part is how to write a stable test because estimating > how many changes are enough for the configured wal_receiver_timeout to > pass on all the buildfarm machines is tricky. Also, I am not sure how > important is to test this behavior because based on this theory we > should have tests for all kinds of timeouts. Yse, I think we could not guarantee the stability of this test. In addition, if we set wal_receiver_timeout too small, it may cause timeout unrelated to this bug. And if we set bigger wal_receiver_timeout and use larger transaction in order to minimize the impact of machine performance, I think this might take some time and might risk making the build farm slow. Regards, Wang wei
В списке pgsql-hackers по дате отправления: