Re: Adding a LogicalRepWorker type field

From: shveta malik <shveta(dot)malik(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Peter Smith <smithpb2250(at)gmail(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, shveta malik <shveta(dot)malik(at)gmail(dot)com>
Subject: Re: Adding a LogicalRepWorker type field
Date: 2023-08-18 03:49:10
Message-ID: CAJpy0uBv8zC4QPtKyHTwUHFHYiLg2m0ZS8C=BcVb5dmUfG5N5A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Aug 18, 2023 at 8:50 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Mon, Aug 14, 2023 at 12:08 PM Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
> >
> > The main patch for adding the worker type enum has been pushed [1].
> >
> > Here is the remaining (rebased) patch for changing some previous
> > cascading if/else to switch on the LogicalRepWorkerType enum instead.
> >
>
> I see this as being useful if we plan to add more worker types. Does
> anyone else see this remaining patch as an improvement?
>

I feel it does give a tad bit more clarity for cases where we have
'else' part with no clear comments or relevant keywords. As an
example, in function 'should_apply_changes_for_rel' , we have:
else
return (rel->state == SUBREL_STATE_READY ||
(rel->state == SUBREL_STATE_SYNCDONE &&
rel->statelsn <= remote_final_lsn));

It is difficult to figure out which worker is this if I do not know
the concept completely; 'case WORKERTYPE_APPLY' makes it better for
the reader to understand.

thanks
Shveta

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Smith 2023-08-18 03:51:38 Re: [PoC] pg_upgrade: allow to upgrade publisher node
Previous Message Masahiro Ikeda 2023-08-18 03:27:02 Rethink the wait event names for postgres_fdw, dblink and etc