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

From Eric Ridge
Subject Re: Threading in BGWorkers (!)
Date
Msg-id CANcm6wbb_AHg3d1baW5cZTew1gPQFFdPqvYCWbBP7J1bJi7BDQ@mail.gmail.com
Whole thread Raw
In response to Re: Threading in BGWorkers (!)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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 <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 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


pgsql-hackers by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions
Next
From: Michael Paquier
Date:
Subject: Re: Removal of currtid()/currtid2() and some table AM cleanup