Re: BUG #16643: PG13 - Logical replication - initial startup never finishes and gets stuck in startup loop
От | Amit Kapila |
---|---|
Тема | Re: BUG #16643: PG13 - Logical replication - initial startup never finishes and gets stuck in startup loop |
Дата | |
Msg-id | CAA4eK1J3+4wT_biGP7ud=JFq-KUeH-BF5AwY_Xgay9AsGMAPQw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #16643: PG13 - Logical replication - initial startup never finishes and gets stuck in startup loop (Peter Smith <smithpb2250@gmail.com>) |
Список | pgsql-bugs |
On Tue, Nov 17, 2020 at 7:44 AM Peter Smith <smithpb2250@gmail.com> wrote: > > On Tue, Nov 17, 2020 at 1:07 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > > Yeah, this seems to be possible and this is the reason I mentioned > > above to dig more into this case. Did you try it via some test case? I > > think we can generate a test via debugger where after the tablesync > > worker reaches CATCHUP state stop it via debugger, then we can perform > > some large transaction on the same table which apply worker will skip > > and tablesync worker will try to apply changes and should fail. > > Hello Amit. > > FYI - This email is just to confirm that your above idea for debugging > the tablesync worker does work. > Thanks for trying this out. > --- > > I have so far only been trying above with the non-streaming > subscription, and TBH stepping through this startup state "dance" of > the tablesync/apply workers is already causing more questions than > answers for me. Anyway, I will raise any questions as separate emails > to this one. > > BTW, do you think these tablesync discussions should be moved to > hackers list? > Sure. I think it is better to start a new thread for the streaming issue we have suspected here and possible ways to fix the same. I guess you have some other observations as well which you might want to discuss separately. -- With Regards, Amit Kapila.
В списке pgsql-bugs по дате отправления: