Re: Perform streaming logical transactions by background workers and parallel apply - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Perform streaming logical transactions by background workers and parallel apply
Date
Msg-id CAA4eK1LGdfTj212PY7rpkzi9PmDEVwPgYTed-_jB6BnMT_aRJQ@mail.gmail.com
Whole thread Raw
In response to Re: Perform streaming logical transactions by background workers and parallel apply  (Peter Smith <smithpb2250@gmail.com>)
Responses Re: Perform streaming logical transactions by background workers and parallel apply
List pgsql-hackers
On Fri, Aug 19, 2022 at 3:05 PM Peter Smith <smithpb2250@gmail.com> wrote:
>
> On Fri, Aug 19, 2022 at 7:10 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > On Fri, Aug 19, 2022 at 2:36 PM Peter Smith <smithpb2250@gmail.com> wrote:
> > >
> > > Here are my review comments for the v23-0005 patch:
> > >
> > > ======
> > >
> > > Commit Message says:
> > > main_worker_pid is Process ID of the main apply worker, if this process is a
> > > apply background worker. NULL if this process is a main apply worker or a
> > > synchronization worker.
> > > The new column can make it easier to distinguish main apply worker and apply
> > > background worker.
> > >
> > > --
> > >
> > > Having a column called ‘main_worker_pid’ which is defined to be NULL
> > > if the process *is* the main apply worker does not make any sense to
> > > me.
> > >
> >
> > I haven't read this part of a patch but it seems to me we have
> > something similar for parallel query workers. Refer 'leader_pid'
> > column in pg_stat_activity.
> >
>
> IIUC (from the patch 0005 commit message) the intention is to be able
> to easily distinguish the worker types.
>

I think it is only to distinguish between leader apply worker and
background apply workers. The tablesync worker can be distinguished
based on relid field.

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: Re: Perform streaming logical transactions by background workers and parallel apply
Next
From: Christoph Berg
Date:
Subject: Re: pg_receivewal and SIGTERM