0

PostgreSQL makes use of background workers to allow processes working in a concurrent fashion and they have an API for backend/extension developers to control them. So far, I have managed to successfully work with this feature in a demo extension, successfully spawning a number of workers.

I am in a situation where one of my workers has to wait for another to finish. What I am doing so far is an infinite loop on an idle worker until the worker being waited for is finished, which can be quite inefficient. So I was wondering how would I go about making the idle process sleep until some signal is sent? What would I be looking for? Is there an extension which does something similar so that I could use for guidance?

Zeruno
  • 1,391
  • 2
  • 20
  • 39
  • What sort of signal? Is it [signal(2)](https://www.mankier.com/2/signal)? Or anything else? Have you read about [select(2)](https://www.mankier.com/2/select)/[poll(2)](https://www.mankier.com/2/poll) like functions? If you're using Linux, you can also use [eventfd(2)](https://www.mankier.com/2/eventfd).. – Unmanned Player Mar 04 '20 at 02:41
  • Not referring to any specific signal but rather something which is available in the PostgreSQL API backend to help me achieve my goal (if at all available). Thank you for your recommendations, I will try making use of them if the PostgreSQL backend does not offer such functionality. – Zeruno Mar 04 '20 at 03:11

2 Answers2

1

You could use advisory locks. They are not tied to transactions.

Another option is to use "light-weight locks" (LWlock), a.k.a. latches, which are available in the backend.

Laurenz Albe
  • 209,280
  • 17
  • 206
  • 263
  • I found the /src/backend/storage/lmgr/condition_variable.c file to have what I want, but I am still trying to evaluate LWlock as an option. I am struggling a bit to understand what LWlocks are from the code. Could you help me understand how LWlock differs from spinlocks or in what way LWlock is "lightweight"? – Zeruno Mar 16 '20 at 03:10
  • With a spinlock, the waiting process does not relinquish the CPU, but performs "busy waiting". That is useful for locks that are guaranteed to be held for a **very** short time. Lightweight locks avoid the full machinery of the heavyweight locks that you can use from SQL. For example, the deadlock detector is not involved. – Laurenz Albe Mar 16 '20 at 04:39
  • Thanks so much! It's much clearer now and a great help. However, I have to accept the condition variable as the answer to the original question as it is closest to the mechanism I am looking for. – Zeruno Mar 16 '20 at 05:05
1

I think the official way to do something like this is with condition variables, implemented in the file src/backend/storage/lmgr/condition_variable.c

I don't see it being used in any "contrib" extensions, however, just the core code.

jjanes
  • 37,812
  • 5
  • 27
  • 34