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 | 911656.1601501524@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #16643: PG13 - Logical replication - initial startup never finishes and gets stuck in startup loop (Henry Hinze <henry.hinze@gmail.com>) |
Ответы |
Re: BUG #16643: PG13 - Logical replication - initial startup never finishes and gets stuck in startup loop
Re: BUG #16643: PG13 - Logical replication - initial startup never finishes and gets stuck in startup loop Re: BUG #16643: PG13 - Logical replication - initial startup never finishes and gets stuck in startup loop |
Список | pgsql-bugs |
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. 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.) 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. regards, tom lane
В списке pgsql-bugs по дате отправления: