On Wed, Feb 3, 2021 at 2:51 PM Peter Smith <smithpb2...@gmail.com> wrote: > > On Wed, Feb 3, 2021 at 1:34 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > On Wed, Feb 3, 2021 at 6:38 AM Peter Smith <smithpb2...@gmail.com> wrote: > > > > > > On Wed, Feb 3, 2021 at 12:26 AM Amit Kapila <amit.kapil...@gmail.com> > > > wrote: > > > > > > > > On Tue, Feb 2, 2021 at 3:31 PM Peter Smith <smithpb2...@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. >
Since this is an existing PG bug independent of this patch, I spawned a new thread [ps0202] to deal with this problem. ---- [ps0202] https://www.postgresql.org/message-id/CAHut%2BPu7Z4a%3Domo%2BTvK5Gub2hxcJ7-3%2BBu1FO_%2B%2BfpFTW0oQfQ%40mail.gmail.com Kind Regards, Peter Smith. Fujitsu Australia
