> 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.
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.
