On Wednesday, June 14, 2023 10:11 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Tue, Jun 13, 2023 at 2:25 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > On Fri, May 12, 2023 at 3:28 PM Zhijie Hou (Fujitsu) > > <houzj.f...@fujitsu.com> wrote: > > > > > > > > > I can reproduce this via gdb following similar steps in [1]. > > > > > > I think we need to move this call into a transaction as well and > > > here is an attempt to do that. > > > > > > > I am able to reproduce this issue following the steps mentioned by you > > and the proposed patch to fix the issue looks good to me. > > > > Today, again looking at the patch, it seems to me that it would be better if > we > can fix this without starting a new transaction. Won't it be better if we > move this > syscall to a place where we are fetching relstate (GetSubscriptionRelState()) > a > few lines above? I understand by doing that in some cases like when copy_data > = false, we may do this syscall unnecessarily but OTOH, starting a new > transaction just for a syscall (superuser_arg()) also doesn't seem like a good > idea to me.
Makes sense to me, here is the updated patch which does the same. Best Regards, Hou zj
v2-0001-Fix-possible-logical-replication-table-sync-crash.patch
Description: v2-0001-Fix-possible-logical-replication-table-sync-crash.patch
