Re: BUG #16643: PG13 - Logical replication - initial startup never finishes and gets stuck in startup loop
Alvaro Herrera <alvherre@alvh.no-ip.org>
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Henry Hinze <henry.hinze@gmail.com>, pgsql-bugs@lists.postgresql.org
Date: 2020-10-02T00:08:54Z
Lists: pgsql-bugs
Attachments
- 0001-Restore-double-command-completion-tags.patch (text/x-diff)
On 2020-Oct-01, Peter Eisentraut wrote: > On 2020-09-30 23:32, Tom Lane wrote: > > The question that this raises is how the heck did that get past > > our test suites? It seems like the error should have been obvious > > to even the most minimal testing. > > 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? 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.
Commits
-
Fix replication of in-progress transactions in tablesync worker.
- 0926e96c4934 14.0 landed
-
Review logical replication tablesync code
- b05fe7b442fd 14.0 landed
-
Restore replication protocol's duplicate command tags
- 72e43fc313e9 13.1 landed
- 4e9821b6fac5 14.0 landed