On Friday, January 13, 2023 1:02 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> On Fri, Jan 13, 2023 at 1:28 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > On Fri, Jan 13, 2023 at 9:06 AM Amit Kapila <amit.kapila16@gmail.com>
> wrote:
> > >
> > > On Fri, Jan 13, 2023 at 7:56 AM Peter Smith <smithpb2250@gmail.com>
> wrote:
> > > >
> > >
> > > >
> > > > 3.
> > > >
> > > > <entry role="catalog_table_entry"><para
> > > > role="column_definition">
> > > > + <structfield>leader_pid</structfield> <type>integer</type>
> > > > + </para>
> > > > + <para>
> > > > + Process ID of the leader apply worker if this process is a parallel
> > > > + apply worker; NULL if this process is a leader apply worker or
> does not
> > > > + participate in parallel apply, or a synchronization worker
> > > > + </para></entry>
> > > >
> > > > I felt this change is giving too many details and ended up just
> > > > muddying the water.
> > > >
> > >
> > > I see that we give a similar description for other parameters as well.
> > > For example leader_pid in pg_stat_activity,
> > >
> >
> > BTW, shouldn't we update leader_pid column in pg_stat_activity as well
> > to display apply leader PID for parallel apply workers? It will
> > currently display for other parallel operations like a parallel
> > vacuum, so I don't see a reason to not do the same for parallel apply
> > workers.
>
> +1
>
> The parallel apply workers have different properties than the parallel query
> workers since they execute different transactions and don't use group locking
> but it would be a good hint for users to show the leader and parallel apply
> worker processes are related. If users want to check only parallel query workers
> they can use the backend_type column.
Agreed, and changed as suggested.
Attach the new version patch set which address the comments so far.
Best Regards,
Hou zj