From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, James Sewell <james(dot)sewell(at)jirotech(dot)com>, Chapman Flack <chap(at)anastigmatix(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Threading in BGWorkers (!) |
Date: | 2020-07-30 18:54:35 |
Message-ID: | 1572791.1596135275@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2020-07-30 19:51:10 | Re: Threading in BGWorkers (!) |
Previous Message | Andres Freund | 2020-07-30 18:46:44 | Re: Threading in BGWorkers (!) |