Re: Add 'worker_type' to pg_stat_subscription
От | Peter Smith |
---|---|
Тема | Re: Add 'worker_type' to pg_stat_subscription |
Дата | |
Msg-id | CAHut+PtxnGzJ0MQM_0rYjdVycjjCk7zdx1YF6fuSUbi+NLo2rg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Add 'worker_type' to pg_stat_subscription (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Add 'worker_type' to pg_stat_subscription
|
Список | pgsql-hackers |
On Tue, Sep 12, 2023 at 1:44 PM Michael Paquier <michael@paquier.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
Вложения
В списке pgsql-hackers по дате отправления: