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 BGWorker which can't be avoided by > >> adhering to strict code rules (eg: no PG calls from non-main threads, no > >> interaction with signals 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
