Re: Threading in BGWorkers (!)

> 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(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 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
>
>
>