Re: Add 'worker_type' to pg_stat_subscription

On Tue, Sep 12, 2023 at 1:44 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Tue, Sep 12, 2023 at 01:07:51PM +1000, Peter Smith wrote:
> > The type is only assigned during worker process launch, and during
> > process cleanup [1]. It's only possible to be UNKNOWN after
> > logicalrep_worker_cleanup().
> >
> > AFAIK the stats can never see a worker with an UNKNOWN type, although
> > it was due to excessive caution against something unforeseen that my
> > original code did below instead of the elog.
> >
> > + case WORKERTYPE_UNKNOWN: /* should not be possible */
> > + nulls[9] = true;
> >
> > Adding "unknown" for something that is supposed to be impossible might
> > be slight overkill, but so long as there is no obligation to write
> > about "unknown" in the PG DOCS then I agree it is probably better to
> > do that,
>
> Using an elog() is OK IMO. pg_stat_get_subscription() holds
> LogicalRepWorkerLock in shared mode, and the only code path setting a
> worker to WORKERTYPE_UNKNOWN requires that this same LWLock is hold in
> exclusive mode while resetting all the shmem fields of the
> subscription entry cleaned up, which is what
> pg_stat_get_subscription() uses to check if a subscription should be
> included in its SRF.
>
> Shouldn't this patch add or tweak some SQL queries in
> src/test/subscription/ to show some worker types, at least?

Right. I found just a single test currently using pg_stat_subscription
catalog. I added a worker_type check for that.

PSA v5

------
Kind Regards,
Peter Smith.
Fujitsu Australia