From: | Masahiro Ikeda <ikedamsh(at)oss(dot)nttdata(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Support to define custom wait events for extensions |
Date: | 2023-06-16 11:44:53 |
Message-ID: | 9b7a7edfc9fbe8dad9f0e35ada6d0c7e@oss.nttdata.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2023-06-16 16:46, Michael Paquier wrote:
> On Fri, Jun 16, 2023 at 11:14:05AM +0900, Masahiro Ikeda wrote:
>> I tried to query on pg_stat_activity to check the background worker
>> invoked by pg_prewarm. But, I found that pg_stat_activity doesn't show
>> it although I may be missing something...
>>
>> So, I tried to implement TAP tests. But I have a problem with it.
>> I couldn't find the way to check the status of another backend
>> while the another backend wait with custom wait events.
>
> Hmm. Right. It seems to me that BGWORKER_BACKEND_DATABASE_CONNECTION
> is required in this case, with BackgroundWorkerInitializeConnection()
> to connect to a database (or not, like the logical replication
> launcher if only access to shared catalogs is wanted).
>
> I have missed that the leader process of pg_prewarm does not use that,
> because it has no need to connect to a database, but its workers do.
> So it is not going to show up in pg_stat_activity.
Yes. Thanks to your advice, I understood that
BGWORKER_BACKEND_DATABASE_CONNECTION is the reason.
I could make the TAP test that invokes a background worker waiting
forever
and checks its custom wait event in pg_stat_activity. So, I'll make
patches
including test codes next week.
Regards,
--
Masahiro Ikeda
NTT DATA CORPORATION
From | Date | Subject | |
---|---|---|---|
Next Message | jian he | 2023-06-16 11:57:05 | Re: Do we want a hashset type? |
Previous Message | shveta malik | 2023-06-16 10:31:37 | Re: Support logical replication of DDLs |