Re: Adding a LogicalRepWorker type field - Mailing list pgsql-hackers

From Peter Smith
Subject Re: Adding a LogicalRepWorker type field
Date
Msg-id CAHut+Psp4wwaLXY8acWmHGRX8e+s3VvB+GRTFj3Wdj2U_akmdw@mail.gmail.com
Whole thread Raw
In response to Re: Adding a LogicalRepWorker type field  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Adding a LogicalRepWorker type field
List pgsql-hackers
On Fri, Aug 11, 2023 at 7:33 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Thu, Aug 10, 2023 at 7:50 AM Peter Smith <smithpb2250@gmail.com> wrote:
> >
> > >
> > > * If you do the above then there won't be a need to change the
> > > variable name is_parallel_apply_worker in logicalrep_worker_launch.
> > >
> >
> > Done.
> >
>
> I don't think the addition of two new macros isTablesyncWorker() and
> isLeaderApplyWorker() adds much value, so removed those and ran
> pgindent. I am planning to commit this patch early next week unless
> you or others have any comments.
>

Thanks for considering this patch fit for pushing.

Actually, I recently found 2 more overlooked places in the launcher.c
code which can benefit from using the isTablesyncWorker(w) macro that
was removed in patch v6-0001.

I have posted another v7.  (v7-0001 is identical to v6-0001). The
v7-0002 patch has the isTablesyncWorker changes. I think wherever
possible it is better to check the worker-type via macro instead of
deducing it by fields like 'relid', and patch v7-0002 makes the code
more consistent with other nearby isParallelApplyWorker checks in
launcher.c

------
Kind Regards,
Peter Smith.
Fujitsu Australia

Attachment

pgsql-hackers by date:

Previous
From: Juan José Santamaría Flecha
Date:
Subject: Re: Inconsistent results with libc sorting on Windows
Next
From: vignesh C
Date:
Subject: Re: [PATCH] Reuse Workers and Replication Slots during Logical Replication