| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Masahiro Ikeda <ikedamsh(at)oss(dot)nttdata(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Support worker_spi to execute the function dynamically. |
| Date: | 2023-07-29 02:38:00 |
| Message-ID: | ZMR7iIXxNOP80c9O@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Jul 28, 2023 at 01:34:15PM -0700, Andres Freund wrote:
> On 2023-07-28 13:45:29 +0900, Michael Paquier wrote:
>> Having each bgworker on its own schema would be enough to prevent
>> conflicts, but I'd like to add a second thing: a check on
>> pg_stat_activity.wait_event after starting the workers. I have added
>> something like that in the patch I have posted today for the custom
>> wait events at [1] and it enforces the startup sequences of the
>> workers in a stricter way.
>
> Is that very meaningful? ISTM the interesting thing to check for would be that
> the state is idle?
That's interesting for the sake of the other patch to check that the
custom events are reported. Anyway, I am a bit short in time, so I
have applied the simplest fix where the dynamic workers just use a
different base ID to get out of your way.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2023-07-29 02:48:33 | Re: Support worker_spi to execute the function dynamically. |
| Previous Message | Peter Geoghegan | 2023-07-28 21:30:58 | Re: Eager page freeze criteria clarification |