From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Peter Smith <smithpb2250(at)gmail(dot)com> |
Cc: | Nathan Bossart <nathandbossart(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Add 'worker_type' to pg_stat_subscription |
Date: | 2023-09-12 03:43:54 |
Message-ID: | ZP/eekcgZ2S4NEKP@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2023-09-12 03:55:44 | Re: PSQL error: total cell count of XXX exceeded |
Previous Message | Peter Smith | 2023-09-12 03:07:51 | Re: Add 'worker_type' to pg_stat_subscription |