Re: Threading in BGWorkers (!)
От | Tom Lane |
---|---|
Тема | Re: Threading in BGWorkers (!) |
Дата | |
Msg-id | 1572791.1596135275@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Threading in BGWorkers (!) (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Threading in BGWorkers (!)
Re: Threading in BGWorkers (!) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: