Threading in BGWorkers (!)

From: James Sewell <james(dot)sewell(at)jirotech(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Threading in BGWorkers (!)
Date: 2020-06-23 00:17:25
Message-ID: CAANVwEsTPoJSbFwTa98pRR12EbSA1p5sMGZcj0bDZSWYRfQcpg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi hackers,

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.

On IRC RhodiumToad offered the following advice (after a standard there be
dragons here disclaimer, as well as noting this may not be a complete list):

Threading (may) be safe if:

1. all signals will be delivered on the main thread and nowhere else
2. no postgres function will ever be called from anything that's not the
main thread
3. it's safe for postgres to call any system library function, even ones
explicitly marked as not thread safe
4. it's safe for postgres to call sigprocmask()

I can live with 1. and 2 - they are fairly easy as long as you know the
rules.

3. needs to be converted to a list of possible calls - which can be done
and checked, I suppose against the POSIX standards?

4. is not fine (I suppose this is a specific example of 3.), as I think
Postgres would need to be using pthread_sigmask() instead - given looks
like a one line change could pthread_sigmask be used when available?

Are there any other rules which need to be adhered to?

Any thoughts, comments, dire warnings, hand waving? On IRC the general
thought was that any changes could be seen as encouraging threading which
is a bad thing - I would argue if you're writing BGWorkers which have SPI
access you've already got a pretty large area to screw things up in anyway
(if you aren't following the standards / code comments).

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.

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2020-06-23 01:03:20 Re: tag typos in "catalog.sgml"
Previous Message Tom Lane 2020-06-22 23:03:08 Re: Backpatch b61d161c14 (Introduce vacuum errcontext ...)