Andres Freund <and...@anarazel.de> writes: > On 2020-07-28 21:52:20 -0400, Tom Lane wrote: >> 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. In other words, it's *not* safe and never has been. I see no good reason to believe that the signal handler issue is the only one. Even if it is, not being able to call any postgres infrastructure is a pretty huge handicap. So I stand by the position that we need an actual plan here, not just chipping away at one-liner things that might or might not improve matters noticeably. regards, tom lane