0

I’m trying to understand when to use a static background worker vs a dynamic one in PostgreSQL.

From what I know so far:

  • Static workers are registered during postmaster startup
  • Dynamic workers can be started at runtime by a backend

I am building an extension that may need a bgw in the future. I am confused whether the extension must be listed in shared_preload_libraries or not. Since bgw can be registered on extension load, is there still a need to preload it, The bgw can also be created at runtime anyway.

So I want to know:

  • What is the exact difference between static and dynamic bgw in behavior and lifecycle

  • What can static bgw do that dynamic bgw cannot

  • In which cases should an extension use static bgw and require shared_preload_libraries

Any guidance or examples for deciding between the two

Thanks in advance.

Improve this question
1

1 Answer 1

Reset to default
1

The main reasons to start a background worker at server start via shared_preload_libraries are:

  • if you need to allocate resources like a shared memory segmment, which you can only do at aerver start

  • if you need the worker to run all the time, not only when a user explicitly starts it (think of pg_timetable)

Other than that, I'd say you should choose what fits your use case better.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

> if you need to allocate resources like a shared memory segmment ---- But since we already have dynamic shared memory in postgres is this still helpeful? > if you need the worker to run all the time ----- A small doubt here if a static worker is crashed it gets restarted by postmaster, is this same for dynamic bgw too?
Static shared memory segments are simpler. I don't know if dynamic workers get restarted automatically, but I foubt it.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.