On Fri, Aug 19, 2022 at 7:55 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Fri, Aug 19, 2022 at 3:05 PM Peter Smith <smithpb2...@gmail.com> wrote: > > > > On Fri, Aug 19, 2022 at 7:10 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > > > On Fri, Aug 19, 2022 at 2:36 PM Peter Smith <smithpb2...@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. >
Right. But that's the reason for my question in the first place - why implement the patch so that the user still has to jump through hoops just to know the worker type information? e.g. Option 1 (patch) - if there is a non-NULL relid field then the worker type must be a tablesyc worker, otherwise if there is non-NULL a leader_pid field then the worker type must be an apply background worker, otherwise the worker type must be an apply main worker. versus Option 2 - new worker_type field (values 't','p','a') ------ Kind Regards, Peter Smith. Fujitsu Australia
