Init scripts hang on `set_config` when a SQL file is provided
gfrn opened this issue · comments
I've dumped an existing database with pg_dump -U $POSTGRES_DB -h $HOST -d $DATABASE > dump.sql
(names altered for brevity and privacy), and once I added this file to /docker-entrypoint-initdb.d
, the container hung on startup indefinitely.
On closer inspection, once queries were echo'd out, it hung on the following line, which is just a standard search_path
vulnerability mitigation:
SELECT pg_catalog.set_config('search_path', '', false);
It also hangs on any other similar functions, such as pg_catalog.setval('public."Item_itemId_seq"', 40, true);
. I've left the container running for roughly 16 hours, but it did not progress any further.
However, when I create an empty database, and restore the data with psql -U $POSTGRES_DB -h $HOST -d $DATABASE -f data.sql
from outside the container, it does so with no issue at all.
The container is also able to complete the initialisation process if I comment out any lines mentioning pg_catalog
.
Asking pg_dump
to create a dump file that performs a clean restore, creating all databases also does not help, since set_config
is invoked before any databases are dropped.
Postgres configs are all default.
Versions tested: 16.1-bookworm
, 13.13-bookworm
, 12.17-bookworm
Dockerfile:
FROM postgres:16.1-bookworm
WORKDIR /docker-entrypoint-initdb.d
ADD dump.sql /docker-entrypoint-initdb.d/dump.sql
# ... ENVs go here
EXPOSE 5432```