Re: Threading in BGWorkers (!)
| От | Eric Ridge |
|---|---|
| Тема | Re: Threading in BGWorkers (!) |
| Дата | |
| Msg-id | CANcm6wbb_AHg3d1baW5cZTew1gPQFFdPqvYCWbBP7J1bJi7BDQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Threading in BGWorkers (!) (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-hackers |
> dispatch the threaded work to a non-Postgres-ish process
I’m no expert here but all your solid points about threading with Postgres notwithstanding....
I think there’s some issues around interrupt handling and general syscalls that doesn’t otherwise play nice with “non-Postgres-ish” *threads* when Postgres is still the main thread.
This is all purely hypothetical, but it seems that Postgres’ use of sigprocmask can cause problems with threads that are otherwise 100% “disconnected” from Postgres.
How can we start a dialog about this kind of situation? Nobody here is trying to make Postgres thread-safe, maybe only thread-friendly.
I think Mr. Sewell, has a better handle around these topics. But he ain’t the only one interested.
eric
On Mon, Jun 22, 2020 at 9:38 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
James Sewell <james.sewell@jirotech.com> writes:
> I was talking about PostgreSQL and threading on IRC the other day - which I
> know is a frowned upon topic - and just wanted to frame the same questions
> here and hopefully get a discussion going.
I think the short answer about threading in bgworkers (or any other
backend process) is "we don't support it; if you try it and it breaks,
which it likely will, you get to keep both pieces". I'm not sure that
there's any merit in making small dents in that policy. I suspect that
at some point, somebody will try to move those goalposts a long way,
but it will be a large and controversial patch.
Why do you want threads in a bgworker anyway? You could spawn multiple
bgworkers, or you could dispatch the threaded work to a non-Postgres-ish
process as PL/Java does. The only advantage I can see of doing work in a
process that's not at arm's-length is to have access to PG computational
or IPC facilities, and none of that is likely to work safely in a threaded
context.
regards, tom lane
В списке pgsql-hackers по дате отправления: