Re: Add common function ReplicationOriginName.
От | Peter Smith |
---|---|
Тема | Re: Add common function ReplicationOriginName. |
Дата | |
Msg-id | CAHut+PtFLGArpBC8ZPhpokbpFX1S46qpGUOEN7F2otL0Gf-qWQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Add common function ReplicationOriginName. (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: Add common function ReplicationOriginName.
|
Список | pgsql-hackers |
On Wed, Sep 21, 2022 at 8:08 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Wed, Sep 21, 2022 at 3:09 PM Peter Smith <smithpb2250@gmail.com> wrote: > > > > On Wed, Sep 21, 2022 at 3:23 PM Amit Kapila <amit.kapila16@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.
В списке pgsql-hackers по дате отправления: