Re: BUG #16643: PG13 - Logical replication - initial startup never finishes and gets stuck in startup loop

Peter Smith <smithpb2250@gmail.com>

From: Peter Smith <smithpb2250@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>, Petr Jelinek <petr@2ndquadrant.com>, Tom Lane <tgl@sss.pgh.pa.us>, Henry Hinze <henry.hinze@gmail.com>, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Date: 2020-11-18T05:49:12Z
Lists: pgsql-bugs
On Wed, Nov 18, 2020 at 3:17 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > To cut a long story short, a tablesync worker CAN in fact end up
> > processing (e.g. apply_dispatch) streaming messages.
> > So the tablesync worker CAN get into the apply_handle_stream_commit.
> > And this scenario, albeit rare, will crash.
> >
>
> Thank you for reproducing this issue. Dilip, Peter, is anyone of you
> interested in writing a fix for this?

Hi Amit.

FYI - Sorry, I am away/offline for the next 5 days.

However, if this bug still remains unfixed after next Tuesday then I
can look at it then.

---

IIUC there are 2 options:
1) Disallow streaming for the tablesync worker.
2) Make streaming work for the tablesync worker.

I prefer option (a) not only because of the KISS principle, but also
because this is how the tablesync worker was previously thought to
behave anyway. I expect this fix may be like the code that Dilip
already posted [1]
[1] https://www.postgresql.org/message-id/CAFiTN-uUgKpfdbwSGnn3db3mMQAeviOhQvGWE_pC9icZF7VDKg%40mail.gmail.com

OTOH, option (b) fix may or may not be possible (I don't know), but I
have doubts that it is worthwhile to consider making a special fix for
a scenario which so far has never been reproduced outside of the
debugger.

--

Kind Regards,
Peter Smith.
Fujitsu Australia



Commits

  1. Fix replication of in-progress transactions in tablesync worker.

  2. Review logical replication tablesync code

  3. Restore replication protocol's duplicate command tags