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

From James Sewell
Subject Threading in BGWorkers (!)
Date
Msg-id CAANVwEsTPoJSbFwTa98pRR12EbSA1p5sMGZcj0bDZSWYRfQcpg@mail.gmail.com
Whole thread Raw
Responses Re: Threading in BGWorkers (!)
List 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.

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Backpatch b61d161c14 (Introduce vacuum errcontext ...)
Next
From: Michael Paquier
Date:
Subject: Re: tag typos in "catalog.sgml"