Re: Threading in BGWorkers (!) - Mailing list pgsql-hackers

From James Sewell
Subject Re: Threading in BGWorkers (!)
Date
Msg-id CAANVwEuWYWYFfCmz8qC4_gNx832U-BnEET6DC4bxDjdR9Hr-XA@mail.gmail.com
Whole thread Raw
In response to Re: Threading in BGWorkers (!)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, 23 Jun 2020 at 13:38, 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 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.

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Update InsertPgAttributeTuple comment to match new signature
Next
From: Amit Kapila
Date:
Subject: Re: min_safe_lsn column in pg_replication_slots view