Horton

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

Amit Kapila <amit.kapila16@gmail.com>

View thread View on postgr.es
From: Amit Kapila <amit.kapila16@gmail.com>
To: Dilip Kumar <dilipbalaut@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-09T10:54:31Z
Lists: pgsql-bugs 
On Mon, Nov 9, 2020 at 1:33 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
>
> On Mon, Nov 9, 2020 at 11:50 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > On Sat, Nov 7, 2020 at 11:33 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> >
> > Sure, but why do we want to prohibit streaming in tablesync worker
> > unless there is some fundamental reason for the same? If we can write
> > a test based on what I described above then we can probably know if
> > there is any real issue with allowing streaming via tablesync worker.
>
> I think there is no fundamental reason for the same,  but I thought it
> is just an initial catchup state so does it make sense to stream the
> transaction.  But if we want to stream then we need to put some
> handling in apply_handle_stream_commit so that it can avoid committing
> if this is the table-sync worker.
>

Sure, let's try that then instead of blindly avoid streaming if it is possible.

-- 
With Regards,
Amit Kapila.

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