Bug: FATAL: database "splitpro" does not exist

[Silther]

Describe the bug
if I look in the portainer logs of my postgres container I get the following error:
´FATAL: database "splitpro" does not exist´
but everything still works.
This error is not new ( at least a week old

To Reproduce
Steps to reproduce the behavior:

1. Go to your docker postgress logs

Expected behavior
should only show errors if something is wrong

Screenshots

App version
v1.5.1

Additional context

compose:

postgres:
container_name: splitpro-postgres
image: postgres:16
restart: unless-stopped
volumes:
- path/splitpro/database:/var/lib/postgresql/data
env_file:
- .env
healthcheck:
test: ['CMD-SHELL', 'pg_isready -U ${POSTGRES_USER}']
interval: 10s
timeout: 5s
retries: 5

.env:

postgres

POSTGRES_USER=splitpro
POSTGRES_PASSWORD=password
POSTGRES_DB=splitprodb
POSTGRES_PORT=5432

DATABASE_URL=postgresql://splitpro:password@postgres:5432/splitprodb

[krokosik]

Please do not post bug reports without reproduction steps. How am I supposed to debug it? I have no knowledge of what you did with your database, so what you wrote as reproductions steps is useless to me, as it assumes I have the same logs as you. Try to setup a fresh instance and find a deterministic way to replicate the issue.

[Silther]

How should I post reproduction steps if this error just gets spammed into docker logs everytime I start up the postgres container?

I have posted the parts of my conpose file which are relevant.
I dont know what else I can do.

[krokosik]

How should I help you if I can't replicate your issue and don't have access to your machine?

Does the issue happen when you start a clean DB, with DB volume deleted beforehand?

[Silther]

The interesting fact is, that its not caused by the splitpro server, even when I only start the postgres container it shows the error.

Does the issue happen when you start a clean DB, with DB volume deleted beforehand?

Yes

The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.
The database cluster will be initialized with locale "en_US.utf8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".
Data page checksums are disabled.
fixing permissions on existing directory /var/lib/postgresql/data ... ok
creating subdirectories ... ok
selecting dynamic shared memory implementation ... posix
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting default time zone ... Europe/Berlin
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
initdb: warning: enabling "trust" authentication for local connections
initdb: hint: You can change this by editing pg_hba.conf or using the option -A, or --auth-local and --auth-host, the next time you run initdb.
syncing data to disk ... ok
Success. You can now start the database server using:
pg_ctl -D /var/lib/postgresql/data -l logfile start
waiting for server to start....2025-09-04 15:39:52.168 CEST [49] LOG: starting PostgreSQL 16.10 (Debian 16.10-1.pgdg13+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 14.2.0-19) 14.2.0, 64-bit
2025-09-04 15:39:52.169 CEST [49] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2025-09-04 15:39:52.175 CEST [52] LOG: database system was shut down at 2025-09-04 15:39:51 CEST
2025-09-04 15:39:52.179 CEST [49] LOG: database system is ready to accept connections
done
server started
CREATE DATABASE
/usr/local/bin/docker-entrypoint.sh: ignoring /docker-entrypoint-initdb.d/*
waiting for server to shut down...2025-09-04 15:39:52.372 CEST [49] LOG: received fast shutdown request
.2025-09-04 15:39:52.373 CEST [49] LOG: aborting any active transactions
2025-09-04 15:39:52.375 CEST [49] LOG: background worker "logical replication launcher" (PID 55) exited with exit code 1
2025-09-04 15:39:52.376 CEST [50] LOG: shutting down
2025-09-04 15:39:52.377 CEST [50] LOG: checkpoint starting: shutdown immediate
2025-09-04 15:39:52.520 CEST [50] LOG: checkpoint complete: wrote 926 buffers (5.7%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.016 s, sync=0.121 s, total=0.145 s; sync files=301, longest=0.002 s, average=0.001 s; distance=4273 kB, estimate=4273 kB; lsn=0/191F0E0, redo lsn=0/191F0E0
2025-09-04 15:39:52.528 CEST [49] LOG: database system is shut down
done
server stopped
PostgreSQL init process complete; ready for start up.
2025-09-04 15:39:52.601 CEST [1] LOG: starting PostgreSQL 16.10 (Debian 16.10-1.pgdg13+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 14.2.0-19) 14.2.0, 64-bit
2025-09-04 15:39:52.602 CEST [1] LOG: listening on IPv4 address "0.0.0.0", port 5432
2025-09-04 15:39:52.602 CEST [1] LOG: listening on IPv6 address "::", port 5432
2025-09-04 15:39:52.604 CEST [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2025-09-04 15:39:52.608 CEST [65] LOG: database system was shut down at 2025-09-04 15:39:52 CEST
2025-09-04 15:39:52.613 CEST [1] LOG: database system is ready to accept connections
2025-09-04 15:40:01.253 CEST [76] FATAL: database "splitpro" does not exist

[Silther]

could it be the health check?

healthcheck:
  test: ['CMD-SHELL', 'pg_isready -U ${POSTGRES_USER}']
  interval: 10s
  timeout: 5s
  retries: 5

The timing would fit, as the error happens every 10s almost exactly

[Silther]

if I change the health check to this:

    healthcheck:
      test: ['CMD-SHELL', 'pg_isready -U ${POSTGRES_DB}']
      interval: 10s
      timeout: 5s
      retries: 5

I get the error:

PostgreSQL Database directory appears to contain a database; Skipping initialization

2025-09-04 15:49:29.022 CEST [1] LOG: starting PostgreSQL 16.10 (Debian 16.10-1.pgdg13+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 14.2.0-19) 14.2.0, 64-bit

2025-09-04 15:49:29.022 CEST [1] LOG: listening on IPv4 address "0.0.0.0", port 5432

2025-09-04 15:49:29.022 CEST [1] LOG: listening on IPv6 address "::", port 5432

2025-09-04 15:49:29.024 CEST [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"

2025-09-04 15:49:29.029 CEST [29] LOG: database system was shut down at 2025-09-04 15:49:28 CEST

2025-09-04 15:49:29.033 CEST [1] LOG: database system is ready to accept connections

2025-09-04 15:49:39.054 CEST [40] FATAL: role "splitprodb" does not exist

2025-09-04 15:49:49.142 CEST [48] FATAL: role "splitprodb" does not exist

[krokosik]

Okay, I think I found the fix. Can you try setting the command to test: ['CMD-SHELL', 'pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}']

[Silther]

Okay, I think I found the fix. Can you try setting the command to test: ['CMD-SHELL', 'pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}']

I have it running for around 5 min with this change without any errors, seems to work fine now.