Re: Threading in BGWorkers (!)

On Tue, 23 Jun 2020 at 13:38, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> James Sewell <james(dot)sewell(at)jirotech(dot)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.