Andres Freund <andres@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