Hi,
On 2020-07-28 21:52:20 -0400, Tom Lane wrote:
> >> The rationale here is that as far as I can tell this is the *only* blocker to using multithreaded code in a
BGWorkerwhich can't be avoided by adhering to strict code rules (eg: no PG calls from non-main threads, no interaction
withsignals from non-main threads).
>
> TBH, though, I do not buy this argument for a millisecond. I don't
> think that anything is going to come out of multithreading a bgworker
> but blood and tears. Perhaps someday we'll make a major push to
> make the backend code (somewhat(?)) thread safe ... but I'm not on
> board with making one-line-at-a-time changes in hopes of getting
> partway there. We need some kind of concrete plan for what is a
> usable amount of functionality and what has to be done to get it.
Why not? Our answer to threading inside functions has been, for quite a
while, that it's kinda ok if the threads never call into postgres and
can never escape the lifetime of a function. But that's not actually
really safe due to the signal handler issue. Whether it's a normal
backend or a bgworker doesn't really play a role here, no?
Greetings,
Andres Freund