Re: Consistent coding for the naming of LR workers - Mailing list pgsql-hackers

From Peter Smith
Subject Re: Consistent coding for the naming of LR workers
Date
Msg-id CAHut+PtWghfm9T1p8U79MRe9U4Otf-zWB0r9dn=nxA836+4L-Q@mail.gmail.com
Whole thread Raw
In response to Re: Consistent coding for the naming of LR workers  (Peter Eisentraut <peter@eisentraut.org>)
Responses Re: Consistent coding for the naming of LR workers
List pgsql-hackers
On Wed, Jul 12, 2023 at 9:35 PM Peter Eisentraut <peter@eisentraut.org> wrote:
>
> On 21.06.23 09:18, Alvaro Herrera wrote:
> > That is a terrible pattern in relatively new code.  Let's get rid of it
> > entirely rather than continue to propagate it.
> >
> >> So, I don't think it is fair to say that these format strings are OK
> >> for the existing HEAD code, but not OK for the patch code, when they
> >> are both the same.
> >
> > Agreed.  Let's remove them all.
>
> This is an open issue for PG16 translation.  I propose the attached
> patch to fix this.  Mostly, this just reverts to the previous wordings.
> (I don't think for these messages the difference between "apply worker"
> and "parallel apply worker" is all that interesting to explode the
> number of messages.  AFAICT, the table sync worker case wasn't even
> used, since callers always handled it separately.)

I thought the get_worker_name function was reachable by tablesync workers also.

Since ApplyWorkerMain is a common entry point for both leader apply
workers and tablesync workers, any logs in that code path could
potentially be from either kind of worker. At least, when the function
was first introduced (around patch v43-0001? [1]) it was also
replacing some tablesync logs.

------
[1] v43-0001 -
https://www.postgresql.org/message-id/OS0PR01MB5716E366874B253B58FC0A23943C9%40OS0PR01MB5716.jpnprd01.prod.outlook.com

Kind Regards,
Peter Smith.
Fujitsu Australia



pgsql-hackers by date:

Previous
From: Andrey Chudnovsky
Date:
Subject: Re: [PoC] Federated Authn/z with OAUTHBEARER
Next
From: Nikolay Samokhvalov
Date:
Subject: Configurable FP_LOCK_SLOTS_PER_BACKEND