> 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 <t...@sss.pgh.pa.us> wrote: > James Sewell <james.sew...@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 > > >
