Re: BUG #16643: PG13 - Logical replication - initial startup never finishes and gets stuck in startup loop
От | Tom Lane |
---|---|
Тема | Re: BUG #16643: PG13 - Logical replication - initial startup never finishes and gets stuck in startup loop |
Дата | |
Msg-id | 1118374.1601601589@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #16643: PG13 - Logical replication - initial startup never finishes and gets stuck in startup loop (PG Bug reporting form <noreply@postgresql.org>) |
Список | pgsql-bugs |
Alvaro Herrera <alvherre@alvh.no-ip.org> writes: > On 2020-Oct-01, Peter Eisentraut wrote: >> What's the difference between this case and what the test suite is testing? >> Is it that it replicates between two databases on the same instance? > I don't know why the tests pass, but the message > ERROR: error reading result of streaming command: > does appear in the logs after running src/test/subscription many times > (I see it in tests 001, 002, 013 and 014, apart from the new one in > 100). It's indeed surprising that these tests all pass! > I turned Henry's reproducer into the attached TAP test, and it does > reproduce the problem; but if I reduce the number of rows from 5000 to > 1000, then it no longer does. I don't quite see why this would be a > problem with a larger table only. Do you? I think we really need to figure that out before concluding that this problem is solved. Now that we've seen this, I'm wondering urgently what other coverage gaps we've got there. > The fix is the commented-out line in walsender.c; the test reliably > passes for me if I uncomment that, and the error message disappear from > the server logs in all the other tests. I agree that this is what we need to do code-wise; we can't let the protocol break stand, or we'll break all sorts of cross-version replication scenarios. However, we'd better also change the protocol spec to say that this is what is supposed to happen. regards, tom lane
В списке pgsql-bugs по дате отправления: