Re: Threading in BGWorkers (!)

From: Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Threading in BGWorkers (!)
Date: 2020-06-23 07:26:16
Message-ID: 9b9fcb9d-005b-0d95-0a59-582d164c2162@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 23.06.2020 10:15, James Sewell wrote:
>
> Using multithreading in bgworker is possible if you do not use any
> Postgres runtime inside thread procedures or do it in exclusive
> critical
> section.
> It is not so convenient but possible. The most difficult thing
> from my
> point of view is error reporting.
>
>
> Happy to be proved wrong, but I don't think this is correct.
> PostgreSQL can call sigprocmask() in your BGWorker whenever it wants,
> and  "The use of sigprocmask() is unspecified in a multithreaded
> process" [1]

Sorry, may be I missed something.
But in my bgworker I am not using Postgres runtime at all (except
initial bgworker startup code).
So I am not using latches (which are based on signals), snapshots,...
In my case bgworker has no connection to Postgres at all.
Yes, it can still receives signals from Postmaster (SIGTERM, SIGHUP).
But their handler are trivial and do not need to mask any signals.

So may be in general case combination of signals and threads may cause
some problems,
but it doesn't mean that you can't create multithreaded bgworker.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message James Sewell 2020-06-23 07:34:21 Re: Threading in BGWorkers (!)
Previous Message James Sewell 2020-06-23 07:18:35 Re: Threading in BGWorkers (!)