# Background writers

DevFeed: [Background writers](<https://devfeed.tech/articles/background-writers-34368.md>)

Original publisher: [Read original article](<https://tapoueh.org/blog/2010/07/background-writers/>)

Author: Dimitri Fontaine PostgreSQL Major Contributor; Author

Published: 2010-07-19T14:30:00Z

Content type: opinion

Language: en

Sources: [Dimitri Fontaine](<https://devfeed.tech/sources/dimitri-fontaine.md>)

Topics: [PostgreSQL](<https://devfeed.tech/topics/postgresql.md>), [Processes](<https://devfeed.tech/topics/processes.md>), [Erlang](<https://devfeed.tech/topics/erlang.md>), [Finite-state machine](<https://devfeed.tech/topics/finite-state-machine.md>)

Tags: [article](<https://devfeed.tech/tags/article.md>), [database](<https://devfeed.tech/tags/database.md>), [erlang](<https://devfeed.tech/tags/erlang.md>), [postgresql](<https://devfeed.tech/tags/postgresql.md>), [processes](<https://devfeed.tech/tags/processes.md>), [worker](<https://devfeed.tech/tags/worker.md>)

## AI overview

The article discusses proposals to generalize PostgreSQL background workers, building on the autovacuum process and related patches. It considers an extensibility API for external processes and workers, drawing ideas from Erlang supervision and finite-state-machine behaviors.

## Source excerpt

There's currently a thread on hackers about bg worker: overview and a series of 6 patches. Thanks a lot Markus! This is all about generalizing a concept already in use in the autovacuum process, where you have an independent subsystem that require having an autonomous daemon running and able to start its own workers. I've been advocating about generalizing this concept for awhile already, in order to have postmaster able to communicate to subsystems when to shut down and start and reload, etc. Some external processes are only external because there's no need to include them by default in to the database engine, not because there's no sense to having them in there.