Is it OK to use multi-thread in Postgresql extension?

Question

I'd like to improve performance of a Postgresql extension and certainly multi-thread is considered. While roughly, I know so far Postgresql is multi-process based, and in the extension, Postgresql things like SRF_FIRSTCALL_INIT(), SRF_PERCALL_SETUP, MemoryContextSwitchTo(), CreateTemplateTupleDesc(), palloc(), Int64GetDatum and so on are used, so my questions:

• Are above APIs thread-safe?
• Is it OK to use multi-thread in Postgresql extension? If so, would you provide any example, or provide any suggestion?
• Is there any multiple process framework is actually preferable for extension? Like LaunchParallelWorker() and RegisterBackgroundWorker(), are they applicable for extension?
• Is there any method to perform something in parallel in extension?

Answer 1

Using threads in a PostgreSQL function is unsafe and forbidden. PostgreSQL has no support for that, and important features like signal handling won't work reliable any more.

PostgreSQL uses signals a lot. For example, if a table definition changes, all processes get a signal that makes them discard all cached metadata and execution plans for that table. With threads, it is not clear which thread of the process handles the signal.

In short: the PostgreSQL backend is not thread-safe, and if you start threads then bad things can happen. Perhaps they won't in your use case, but I certainly wouldn't risk it.

• Qiu Yangfan: Would you help to check my updated question: "Is there any method to perform something in parallel in extension?"
• Qiu Yangfan: Would you also explain more about thread is unsafe and forbidden? Say I just start an idle thread sleeping there by pthread_create(), would it cause any trouble about signal in theory?
• Laurenz Albe: I tried to add some more details.