On Fri, Jan 13, 2023 at 1:28 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Fri, Jan 13, 2023 at 9:06 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > On Fri, Jan 13, 2023 at 7:56 AM Peter Smith <smithpb2...@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
