On Wed, Sep 21, 2022 at 8:08 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Wed, Sep 21, 2022 at 3:09 PM Peter Smith <smithpb2...@gmail.com> wrote: > > > > On Wed, Sep 21, 2022 at 3:23 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > > ... > > > > > Can't we use the existing function ReplicationOriginNameForTablesync() > > > by passing relid as InvalidOid for this purpose? We need a check > > > inside to decide which name to construct, otherwise, it should be > > > fine. If we agree with this, then we can change the name of the > > > function to something like ReplicationOriginNameForLogicalRep or > > > ReplicationOriginNameForLogicalRepWorkers. > > > > > > > This suggestion attaches special meaning to the reild param. > > > > Won't it seem a bit strange for the non-tablesync callers (who > > probably have a perfectly valid 'relid') to have to pass an InvalidOid > > relid just so they can format the correct origin name? > > > > For non-tablesync workers, relid should always be InvalidOid. See, how > we launch apply workers in ApplyLauncherMain(). Do you see any case > for non-tablesync workers where relid is not InvalidOid? >
Hmm, my mistake. I was thinking more of all the calls coming from the subscriptioncmds.c, but now that I look at it maybe none of those has any relid either. OK, I can unify the 2 functions as you suggested. I will post another patch in a few days. ------ Kind Regards, Peter Smith, Fujitsu Australia.
