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: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Henry Hinze <henry.hinze@gmail.com>, pgsql-bugs@lists.postgresql.org
Date: 2020-09-30T21:42:16Z
Lists: pgsql-bugs
On 2020-Sep-30, Tom Lane wrote: > Henry Hinze <henry.hinze@gmail.com> writes: > > I've made an important observation! > > Since I had the impression this setup was already working with RC1 of PG > > 13, I re-installed RC1 and did the same test. And it's working fine! > > Ugh. So that points the finger at commits 07082b08c/bfb12cd2b, > which are the only nearby change between rc1 and 13.0. A quick > comparison of before-and-after checkouts confirms it. Oh dear. > After some digging around, I realize that that commit actually > resulted in a protocol break. libpqwalreceiver is expecting to > get an additional CommandComplete message after COPY OUT finishes, > per libpqrcv_endstreaming(), and it's no longer getting one. > > (I have not read the protocol document to see if this is per spec; > but spec or no, that's what libpqwalreceiver is expecting.) Yeah, definitely. The minimal fix seems to be to add an EndReplicationCommand() call in the T_StartReplicationCmd case. Testing this now ... > 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. ... yeah, that's indeed an important question. I'm going to guess that the TAP suites are too forgiving :-(
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