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 hoping that from this a set of rules rather than a blanket ban can be agreed upon.
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.
Understood, and I do agree with keeping the policy simple - but it looks like (potentially) the only blocker is a one line change to swap out sigprocmask. From my perspective this is a very large win - I'll do some testing.
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.
I'm writing the workers in Rust - it would be nice to be able to safely access Rust crates which make use of threads.
cheers,
James
The contents of this email are confidential and may be subject to legal or professional privilege and copyright. No representation is made that this email is free of viruses or other defects. If you have received this communication in error, you may not copy or distribute any part of it or otherwise disclose its contents to anyone. Please advise the sender of your incorrect receipt of this correspondence.