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.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com