Re: Single transaction in the tablesync worker?
От | Peter Smith |
---|---|
Тема | Re: Single transaction in the tablesync worker? |
Дата | |
Msg-id | CAHut+PtSO4WsZwx8z=+Yp_OWpxFmmFi5WX6OmYJzULNa2NV89g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Single transaction in the tablesync worker? (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: Single transaction in the tablesync worker?
|
Список | pgsql-hackers |
On Wed, Feb 3, 2021 at 1:34 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Wed, Feb 3, 2021 at 6:38 AM Peter Smith <smithpb2250@gmail.com> wrote: > > > > On Wed, Feb 3, 2021 at 12:26 AM Amit Kapila <amit.kapila16@gmail.com> wrote: > > > > > > On Tue, Feb 2, 2021 at 3:31 PM Peter Smith <smithpb2250@gmail.com> wrote: > > > > > > > > After seeing Ajin's test [ac0202] which did a DROP TABLE, I have also > > > > tried a simple test where I do a DROP TABLE with very bad timing for > > > > the tablesync worker. It seems that doing this can cause the sync > > > > worker's MyLogicalRepWorker->relid to become invalid. > > > > > > > > > > I think this should be fixed by latest patch because I have disallowed > > > drop of a table when its synchronization is in progress. You can check > > > once and let me know if the issue still exists? > > > > > > > FYI - I confirmed that the problem scenario that I reported yesterday > > is no longer possible because now the V25 patch is disallowing the > > DROP TABLE while the tablesync is still running. > > > > Thanks for the confirmation. BTW, can you please check if we can > reproduce that problem without this patch? If so, we might want to > apply this fix irrespective of this patch. If not, why not? > Yes, this was an existing postgres bug. It is independent of the patch. I can reproduce exactly the same stacktrace using the HEAD src pulled @ 3/Feb. PSA my test logs showing the details. ---- Kind Regards, Peter Smith. Fujitsu Australia
Вложения
В списке pgsql-hackers по дате отправления: