Re: Single transaction in the tablesync worker?
От | Peter Smith |
---|---|
Тема | Re: Single transaction in the tablesync worker? |
Дата | |
Msg-id | CAHut+Pv7YW7AyO_Q_nf9kzogcJcDFQNe8FBP6yXdzowMz3dY_Q@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 Thu, Jan 7, 2021 at 3:20 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Wed, Jan 6, 2021 at 3:39 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > > > On Wed, Jan 6, 2021 at 2:13 PM Peter Smith <smithpb2250@gmail.com> wrote: > > > > > > I think it makes sense. If there can be a race between the tablesync > > > re-launching (after error), and the AlterSubscription_refresh removing > > > some table’s relid from the subscription then there could be lurking > > > slot/origin tablesync resources (of the removed table) which a > > > subsequent DROP SUBSCRIPTION cannot discover. I will think more about > > > how/if it is possible to make this happen. Anyway, I suppose I ought > > > to refactor/isolate some of the tablesync cleanup code in case it > > > needs to be commonly called from DropSubscription and/or from > > > AlterSubscription_refresh. > > > > > > > Fair enough. > > > > I think before implementing, we should once try to reproduce this > case. I understand this is a timing issue and can be reproduced only > with the help of debugger but we should do that. FYI, I was able to reproduce this case in debugger. PSA logs showing details. ---- Kind Regards, Peter Smith. Fujitsu Australia
Вложения
В списке pgsql-hackers по дате отправления: