[Bug]: Worker slots exhaustion caused by failing to connect to template0 database

[ettanany]

What type of bug is this?

Unexpected error

What subsystems and features are affected?

Background worker

What happened?

Infinite attempts to connect to template0 database (which doesn't allow connections by default) in order to start a scheduler worker for it, seems to cause worker slots exhaustion, leading to failures when trying anything else that requires worker slots (e.g. starting logical replication).

TimescaleDB version affected

2.18.0

PostgreSQL version used

16.6

What operating system did you use?

Alpine 3.21.2

What installation method did you use?

Docker

What platform did you run on?

Not applicable

Relevant log output and stack trace

2025-02-25 17:00:51.759 UTC [92] FATAL:  database "template0" is not currently accepting connections
2025-02-25 17:00:51.761 UTC [1] LOG:  background worker "TimescaleDB Background Worker Scheduler" (PID 92) exited with exit code 1
2025-02-25 17:01:51.766 UTC [125] FATAL:  database "template0" is not currently accepting connections
2025-02-25 17:01:51.770 UTC [1] LOG:  background worker "TimescaleDB Background Worker Scheduler" (PID 125) exited with exit code 1
2025-02-25 17:02:51.778 UTC [150] FATAL:  database "template0" is not currently accepting connections
2025-02-25 17:02:51.781 UTC [1] LOG:  background worker "TimescaleDB Background Worker Scheduler" (PID 150) exited with exit code 1

How can we reproduce the bug?

To reproduce this issue, just create a new database using template0 as a template (or any template that doesn't allow connections). e.g. using Docker:

docker run --name timescaledb -p 5432:5432 -e POSTGRES_PASSWORD=password timescale/timescaledb:2.18.0-pg16

In a second terminal, run the following and check the logs from the previous terminal:

psql -h localhost -U postgres -c 'create database mydb template template0'

Regarding worker slots exhaustion part, in my case I was previously able to replicate at least 2 databases when max_worker_processes is set to its default value (8), but with this issue, the data is not being replicated (as there are not available slots for logical replication apply workers).