I'm using PostgreSQL v11.0. I am executing a simple SQL query
delete from base.sys_attribute where id=20;
It fails and returns the error:
server process (PID 29) was terminated by signal 11 (see log below)
Any idea how I can troubleshoot this issue? I'm completely stuck...
listof-db | 2019-05-10 08:54:46.425 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432
listof-db | 2019-05-10 08:54:46.425 UTC [1] LOG: listening on IPv6 address "::", port 5432
listof-db | 2019-05-10 08:54:46.425 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
listof-db | 2019-05-10 08:54:46.435 UTC [20] LOG: database system was shut down at 2019-05-10 08:54:26 UTC
listof-db | 2019-05-10 08:54:46.438 UTC [1] LOG: database system is ready to accept connections
listof-db | 2019-05-10 08:56:52.295 UTC [1] LOG: server process (PID 29) was terminated by signal 11
listof-db | 2019-05-10 08:56:52.295 UTC [1] DETAIL: Failed process was running: delete from base.sys_attribute where id=20
listof-db | 2019-05-10 08:56:52.295 UTC [1] LOG: terminating any other active server processes
listof-db | 2019-05-10 08:56:52.295 UTC [24] WARNING: terminating connection because of crash of another server process
listof-db | 2019-05-10 08:56:52.295 UTC [24] DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
listof-db | 2019-05-10 08:56:52.295 UTC [24] HINT: In a moment you should be able to reconnect to the database and repeat your command.
listof-db | 2019-05-10 08:56:52.486 UTC [1] LOG: all server processes terminated; reinitializing
listof-db | 2019-05-10 08:56:53.093 UTC [30] LOG: database system was interrupted; last known up at 2019-05-10 08:54:46 UTC
listof-db | 2019-05-10 08:56:53.187 UTC [30] LOG: database system was not properly shut down; automatic recovery in progress
listof-db | 2019-05-10 08:56:53.189 UTC [30] LOG: redo starts at 0/75955A8
listof-db | 2019-05-10 08:56:53.189 UTC [30] LOG: invalid record length at 0/75971B8: wanted 24, got 0
listof-db | 2019-05-10 08:56:53.189 UTC [30] LOG: redo done at 0/7597180
listof-db | 2019-05-10 08:56:53.194 UTC [1] LOG: database system is ready to accept connections
Related
I don't understand this postgresql log :
2022-03-27 08:00:19.441 UTC [584262] postgres#boutique2 FATAL: database "boutique2" does not exist
2022-03-27 08:00:19.704 UTC [584264] postgres#boutique2 FATAL: database "boutique2" does not exist
2022-03-27 08:01:54.770 UTC [781] LOG: received fast shutdown request
2022-03-27 08:01:54.773 UTC [781] LOG: aborting any active transactions
2022-03-27 08:01:54.779 UTC [781] LOG: background worker "logical replication launcher" (PID 800) exited with exit code 1
2022-03-27 08:01:54.780 UTC [795] LOG: shutting down
2022-03-27 08:01:54.797 UTC [781] LOG: database system is shut down
2022-03-27 08:02:16.254 UTC [770] LOG: starting PostgreSQL 13.5 (Debian 13.5-0+deb11u1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit
2022-03-27 08:02:16.255 UTC [770] LOG: listening on IPv4 address "127.0.0.1", port 5432
2022-03-27 08:02:16.256 UTC [770] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2022-03-27 08:02:16.271 UTC [772] LOG: database system was shut down at 2022-03-27 08:01:54 UTC
2022-03-27 08:02:16.285 UTC [770] LOG: database system is ready to accept connections
2022-03-27 08:02:17.243 UTC [891] postgres#boutique2 FATAL: database "boutique2" does not exist
2022-03-27 08:02:17.640 UTC [1044] postgres#boutique2 FATAL: database "boutique2" does not exist
I dropped this database, which is not present in my mojolicious scripts, the only ones on this server.
root#perso:/etc/postgresql/13/main# grep postgresql.conf -e 'boutique2'
root#perso:/etc/postgresql/13/main# grep pg_hba.conf -e 'boutique2'
root#perso:/etc/postgresql/13/main#
Has please someone an idea about ?
I want to install Hasura using docker. According to the Hasura doc, I created the docker-compose.yml file. then I compose docker with docker-compose up. In my terminal log, a message comes LOG: database system is ready to accept connections. But when I go to the http://localhost:8080/, I find nothing.
I don't understand where is the problem and how to solve it?
docker-compose.yml file
version: '3.6'
services:
postgres:
image: postgres:12
restart: always
volumes:
- ./db_data:/var/lib/postgresql/data
environment:
POSTGRES_PASSWORD: postgrespassword
graphql-engine:
image: hasura/graphql-engine:v2.0.10
ports:
- "8080:8080"
depends_on:
- "postgres"
restart: always
environment:
## postgres database to store Hasura metadata
HASURA_GRAPHQL_METADATA_DATABASE_URL: postgres://postgres:postgrespassword#postgres:5432/postgres
## this env var can be used to add the above postgres database to Hasura as a data source. this can be removed/updated based on your needs
PG_DATABASE_URL: postgres://postgres:postgrespassword#postgres:5432/postgres
## enable the console served by server
HASURA_GRAPHQL_ENABLE_CONSOLE: "true" # set to "false" to disable console
## enable debugging mode. It is recommended to disable this in production
HASURA_GRAPHQL_DEV_MODE: "true"
HASURA_GRAPHQL_ENABLED_LOG_TYPES: startup, http-log, webhook-log, websocket-log, query-log
## uncomment next line to set an admin secret
# HASURA_GRAPHQL_ADMIN_SECRET: myadminsecretkey
volumes:
db_data:
my terminal:
sumon#error-inside hasura % docker-compose up
hasura_postgres_1 is up-to-date
9675a01ed8fd_hasura_graphql-engine_1 is up-to-date
Attaching to hasura_postgres_1, 9675a01ed8fd_hasura_graphql-engine_1
9675a01ed8fd_hasura_graphql-engine_1 | qemu: uncaught target signal 11 (Segmentation fault) - core dumped
9675a01ed8fd_hasura_graphql-engine_1 | qemu: uncaught target signal 11 (Segmentation fault) - core dumped
9675a01ed8fd_hasura_graphql-engine_1 | qemu: uncaught target signal 11 (Segmentation fault) - core dumped
9675a01ed8fd_hasura_graphql-engine_1 | qemu: uncaught target signal 11 (Segmentation fault) - core dumped
postgres_1 | The files belonging to this database system will be owned by user "postgres".
postgres_1 | This user must also own the server process.
postgres_1 |
postgres_1 | The database cluster will be initialized with locale "en_US.utf8".
postgres_1 | The default database encoding has accordingly been set to "UTF8".
postgres_1 | The default text search configuration will be set to "english".
postgres_1 |
postgres_1 | Data page checksums are disabled.
postgres_1 |
postgres_1 | fixing permissions on existing directory /var/lib/postgresql/data ... ok
postgres_1 | creating subdirectories ... ok
postgres_1 | selecting dynamic shared memory implementation ... posix
postgres_1 | selecting default max_connections ... 100
postgres_1 | selecting default shared_buffers ... 128MB
postgres_1 | selecting default time zone ... Etc/UTC
postgres_1 | creating configuration files ... ok
postgres_1 | running bootstrap script ... ok
postgres_1 | performing post-bootstrap initialization ... ok
postgres_1 | syncing data to disk ... ok
postgres_1 |
postgres_1 |
postgres_1 | Success. You can now start the database server using:
postgres_1 |
postgres_1 | pg_ctl -D /var/lib/postgresql/data -l logfile start
postgres_1 |
postgres_1 | initdb: warning: enabling "trust" authentication for local connections
postgres_1 | You can change this by editing pg_hba.conf or using the option -A, or
postgres_1 | --auth-local and --auth-host, the next time you run initdb.
postgres_1 | waiting for server to start....2021-10-23 04:46:45.991 UTC [50] LOG: starting PostgreSQL 12.8 (Debian 12.8-1.pgdg110+1) on aarch64-unknown-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit
postgres_1 | 2021-10-23 04:46:45.993 UTC [50] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
postgres_1 | 2021-10-23 04:46:46.023 UTC [51] LOG: database system was shut down at 2021-10-23 04:46:44 UTC
postgres_1 | 2021-10-23 04:46:46.039 UTC [50] LOG: database system is ready to accept connections
postgres_1 | done
postgres_1 | server started
postgres_1 |
postgres_1 | /usr/local/bin/docker-entrypoint.sh: ignoring /docker-entrypoint-initdb.d/*
postgres_1 |
postgres_1 | waiting for server to shut down...2021-10-23 04:46:46.242 UTC [50] LOG: received fast shutdown request
postgres_1 | .2021-10-23 04:46:46.243 UTC [50] LOG: aborting any active transactions
postgres_1 | 2021-10-23 04:46:46.245 UTC [50] LOG: background worker "logical replication launcher" (PID 57) exited with exit code 1
postgres_1 | 2021-10-23 04:46:46.245 UTC [52] LOG: shutting down
postgres_1 | 2021-10-23 04:46:46.279 UTC [50] LOG: database system is shut down
postgres_1 | done
postgres_1 | server stopped
postgres_1 |
postgres_1 | PostgreSQL init process complete; ready for start up.
postgres_1 |
postgres_1 | 2021-10-23 04:46:46.358 UTC [1] LOG: starting PostgreSQL 12.8 (Debian 12.8-1.pgdg110+1) on aarch64-unknown-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit
postgres_1 | 2021-10-23 04:46:46.359 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432
postgres_1 | 2021-10-23 04:46:46.359 UTC [1] LOG: listening on IPv6 address "::", port 5432
postgres_1 | 2021-10-23 04:46:46.363 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
postgres_1 | 2021-10-23 04:46:46.395 UTC [69] LOG: database system was shut down at 2021-10-23 04:46:46 UTC
postgres_1 | 2021-10-23 04:46:46.413 UTC [1] LOG: database system is ready to accept connections
postgres_1 | 2021-10-23 04:51:52.553 UTC [1] LOG: received fast shutdown request
postgres_1 | 2021-10-23 04:51:52.555 UTC [1] LOG: aborting any active transactions
postgres_1 | 2021-10-23 04:51:52.556 UTC [1] LOG: background worker "logical replication launcher" (PID 75) exited with exit code 1
postgres_1 | 2021-10-23 04:51:52.559 UTC [70] LOG: shutting down
postgres_1 | 2021-10-23 04:51:52.596 UTC [1] LOG: database system is shut down
postgres_1 |
postgres_1 | PostgreSQL Database directory appears to contain a database; Skipping initialization
postgres_1 |
postgres_1 | 2021-10-23 04:52:02.912 UTC [1] LOG: starting PostgreSQL 12.8 (Debian 12.8-1.pgdg110+1) on aarch64-unknown-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit
postgres_1 | 2021-10-23 04:52:02.913 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432
postgres_1 | 2021-10-23 04:52:02.913 UTC [1] LOG: listening on IPv6 address "::", port 5432
postgres_1 | 2021-10-23 04:52:02.917 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
postgres_1 | 2021-10-23 04:52:02.949 UTC [28] LOG: database system was shut down at 2021-10-23 04:51:52 UTC
postgres_1 | 2021-10-23 04:52:02.967 UTC [1] LOG: database system is ready to accept connections
postgres_1 |
postgres_1 | PostgreSQL Database directory appears to contain a database; Skipping initialization
postgres_1 |
postgres_1 | 2021-10-23 05:09:34.960 UTC [1] LOG: starting PostgreSQL 12.8 (Debian 12.8-1.pgdg110+1) on aarch64-unknown-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit
postgres_1 | 2021-10-23 05:09:34.960 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432
postgres_1 | 2021-10-23 05:09:34.960 UTC [1] LOG: listening on IPv6 address "::", port 5432
postgres_1 | 2021-10-23 05:09:34.964 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
postgres_1 | 2021-10-23 05:09:34.996 UTC [28] LOG: database system was interrupted; last known up at 2021-10-23 04:57:03 UTC
postgres_1 | 2021-10-23 05:09:36.329 UTC [28] LOG: database system was not properly shut down; automatic recovery in progress
postgres_1 | 2021-10-23 05:09:36.342 UTC [28] LOG: redo starts at 0/164DF58
postgres_1 | 2021-10-23 05:09:36.342 UTC [28] LOG: invalid record length at 0/164E058: wanted 24, got 0
postgres_1 | 2021-10-23 05:09:36.342 UTC [28] LOG: redo done at 0/164E020
postgres_1 | 2021-10-23 05:09:36.367 UTC [1] LOG: database system is ready to accept connections
postgres_1 |
postgres_1 | PostgreSQL Database directory appears to contain a database; Skipping initialization
postgres_1 |
postgres_1 | 2021-10-23 05:14:07.556 UTC [1] LOG: starting PostgreSQL 12.8 (Debian 12.8-1.pgdg110+1) on aarch64-unknown-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit
postgres_1 | 2021-10-23 05:14:07.556 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432
postgres_1 | 2021-10-23 05:14:07.556 UTC [1] LOG: listening on IPv6 address "::", port 5432
postgres_1 | 2021-10-23 05:14:07.560 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
postgres_1 | 2021-10-23 05:14:07.591 UTC [28] LOG: database system was interrupted; last known up at 2021-10-23 05:09:36 UTC
postgres_1 | 2021-10-23 05:14:08.941 UTC [28] LOG: database system was not properly shut down; automatic recovery in progress
postgres_1 | 2021-10-23 05:14:08.944 UTC [28] LOG: redo starts at 0/164E0D0
postgres_1 | 2021-10-23 05:14:08.944 UTC [28] LOG: invalid record length at 0/164E108: wanted 24, got 0
postgres_1 | 2021-10-23 05:14:08.944 UTC [28] LOG: redo done at 0/164E0D0
postgres_1 | 2021-10-23 05:14:08.963 UTC [1] LOG: database system is ready to accept connections
postgres_1 | 2021-10-23 06:21:46.578 UTC [32] WARNING: could not open statistics file "pg_stat_tmp/global.stat": Operation not permitted
I may be encountering the same issue described in Horizon: does not exit if database connection fails #898 (https://github.com/stellar/go/issues/898) but with a different set up scenario.
I am in the process of migrating https://github.com/satoshipay/docker-stellar-horizon Docker Compose definitions to Kubernetes. I have been able to migrate most of the set up but hitting a problem with Horizon where the DB is not getting created during startup. I believe I have stellar core with the dependency on Postgres working as designed and the DB created as part of startup but the set up is different for Horizon.
The current issue I am hitting is the following...
Horizon Server Pod Logs
todkapmcbookpro:kubernetes todd$ kubectl get pods
NAME READY STATUS RESTARTS AGE
postgres-horizon-564d479db4-2xvqd 1/1 Running 0 20m
postgres-sc-9f5f7fb4-prlpr 1/1 Running 0 22m
stellar-core-7ff77b4db8-tx4mt 1/1 Running 0 18m
stellar-horizon-6cff98554b-d7djn 0/1 CrashLoopBackOff 8 18m
todkapmcbookpro:kubernetes todd$ kubectl logs stellar-horizon-6cff98554b-d7djn
Initializing Horizon database...
2019/05/02 12:58:09 connect failed: pq: database "stellar-horizon" does not exist
Horizon database initialization failed (possibly because it has been done before)
2019/05/02 12:58:09 pq: database "stellar-horizon" does not exist
todkapmcbookpro:kubernetes todd$
Horizon Postgres DB pod logs
todkapmcbookpro:kubernetes todd$ kubectl logs postgres-horizon-564d479db4-2xvqd
2019-05-02 12:40:06.424 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432
2019-05-02 12:40:06.424 UTC [1] LOG: listening on IPv6 address "::", port 5432
2019-05-02 12:40:06.437 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2019-05-02 12:40:06.444 UTC [23] LOG: database system was interrupted; last known up at 2019-05-02 12:38:19 UTC
2019-05-02 12:40:06.453 UTC [23] LOG: database system was not properly shut down; automatic recovery in progress
2019-05-02 12:40:06.454 UTC [23] LOG: redo starts at 0/1636FB8
2019-05-02 12:40:06.454 UTC [23] LOG: invalid record length at 0/1636FF0: wanted 24, got 0
2019-05-02 12:40:06.454 UTC [23] LOG: redo done at 0/1636FB8
2019-05-02 12:40:06.459 UTC [1] LOG: database system is ready to accept connections
2019-05-02 12:42:35.675 UTC [30] FATAL: database "stellar-horizon" does not exist
2019-05-02 12:42:35.690 UTC [31] FATAL: database "stellar-horizon" does not exist
2019-05-02 12:42:37.123 UTC [32] FATAL: database "stellar-horizon" does not exist
2019-05-02 12:42:37.136 UTC [33] FATAL: database "stellar-horizon" does not exist
2019-05-02 12:42:50.131 UTC [34] FATAL: database "stellar-horizon" does not exist
2019-05-02 12:42:50.153 UTC [35] FATAL: database "stellar-horizon" does not exist
2019-05-02 12:43:16.094 UTC [36] FATAL: database "stellar-horizon" does not exist
2019-05-02 12:43:16.115 UTC [37] FATAL: database "stellar-horizon" does not exist
2019-05-02 12:43:57.097 UTC [38] FATAL: database "stellar-horizon" does not exist
2019-05-02 12:43:57.111 UTC [39] FATAL: database "stellar-horizon" does not exist
2019-05-02 12:45:21.050 UTC [40] FATAL: database "stellar-horizon" does not exist
2019-05-02 12:45:21.069 UTC [41] FATAL: database "stellar-horizon" does not exist
2019-05-02 12:48:05.122 UTC [42] FATAL: database "stellar-horizon" does not exist
2019-05-02 12:48:05.145 UTC [43] FATAL: database "stellar-horizon" does not exist
2019-05-02 12:53:07.077 UTC [44] FATAL: database "stellar-horizon" does not exist
2019-05-02 12:53:07.099 UTC [45] FATAL: database "stellar-horizon" does not exist
2019-05-02 12:58:09.084 UTC [46] FATAL: database "stellar-horizon" does not exist
2019-05-02 12:58:09.098 UTC [47] FATAL: database "stellar-horizon" does not exist
2019-05-02 13:03:18.055 UTC [48] FATAL: database "stellar-horizon" does not exist
2019-05-02 13:03:18.071 UTC [49] FATAL: database "stellar-horizon" does not exist
2019-05-02 13:08:28.057 UTC [50] FATAL: database "stellar-horizon" does not exist
2019-05-02 13:08:28.078 UTC [51] FATAL: database "stellar-horizon" does not exist
2019-05-02 13:13:42.071 UTC [52] FATAL: database "stellar-horizon" does not exist
2019-05-02 13:13:42.097 UTC [53] FATAL: database "stellar-horizon" does not exist
2019-05-02 13:18:55.128 UTC [54] FATAL: database "stellar-horizon" does not exist
2019-05-02 13:18:55.152 UTC [55] FATAL: database "stellar-horizon" does not exist
It would be ideal if the setup for Horizon and Core were the same (especially as it relates to the DB configuration env properties). I think I have the settings correct but may be missing something subtle.
I have a branch of this WIP where the failure occurs. I have included a quick set up script as well as a minikube set up in this branch.
https://github.com/todkap/stellar-testnet/tree/k8-deploy/kubernetes
We were able to resolve and published an article demonstrating the end to end flow.
https://itnext.io/how-to-deploy-a-stellar-validator-on-kubernetes-with-helm-a111e5dfe437
Postgresql wont start in ubuntu 16.04,
Please give support.
These are the error log read:
2018-10-12 13:42:34 UTC [3371-2] LOG: received fast shutdown request
2018-10-12 13:42:34 UTC [3371-3] LOG: aborting any active transactions
2018-10-12 13:42:34 UTC [3376-2] LOG: autovacuum launcher shutting down
2018-10-12 13:42:34 UTC [3373-1] LOG: shutting down
2018-10-12 13:42:34 UTC [3373-2] LOG: database system is shut down
2018-10-12 13:42:52 UTC [3855-1] LOG: database system was shut down at
2018-10-12 13:42:34 UTC
2018-10-12 13:42:52 UTC [3855-2] LOG: MultiXact member wraparound
protections are now enabled
2018-10-12 13:42:52 UTC [3853-1] LOG: database system is ready to accept
connections
2018-10-12 13:42:52 UTC [3859-1] LOG: autovacuum launcher started
2018-10-12 13:42:52 UTC [3861-1] [unknown]#[unknown] LOG: incomplete
startup
packet
According to these docs, I can specify the name of the database created by the postgres docker image with the env var POSTGRES_DB. I have set it in my docker-compose file, but it isn't being created.
Here's relevant section from the compose file:
pg:
image: postgres:10
volumes:
- db-data:/var/lib/postgresql/data
environment:
POSTGRES_DB: user-auth
POSTGRES_USER: postgres
POSTGRES_PASSWORD: postgres
Here are the logs:
Attaching to userauth_pg_1
pg_1 | 2018-02-05 18:05:54.803 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432
pg_1 | 2018-02-05 18:05:54.803 UTC [1] LOG: listening on IPv6 address "::", port 5432
pg_1 | 2018-02-05 18:05:54.806 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
pg_1 | 2018-02-05 18:05:54.817 UTC [24] LOG: database system was interrupted; last known up at 2018-02-05 18:03:26 UTC
pg_1 | 2018-02-05 18:05:54.942 UTC [24] LOG: database system was not properly shut down; automatic recovery in progress
pg_1 | 2018-02-05 18:05:54.944 UTC [24] LOG: redo starts at 0/1633ED0
pg_1 | 2018-02-05 18:05:54.944 UTC [24] LOG: invalid record length at 0/1633F08: wanted 24, got 0
pg_1 | 2018-02-05 18:05:54.944 UTC [24] LOG: redo done at 0/1633ED0
pg_1 | 2018-02-05 18:05:54.955 UTC [1] LOG: database system is ready to accept connections
pg_1 | 2018-02-05 18:05:59.140 UTC [31] FATAL: database "user-auth" does not exist
pg_1 | 2018-02-05 18:06:15.528 UTC [32] FATAL: database "user-auth" does not exist
pg_1 | 2018-02-05 18:08:46.120 UTC [33] FATAL: database "user-auth" does not exist
pg_1 | 2018-02-05 18:08:46.151 UTC [34] FATAL: database "user-auth" does not exist
pg_1 | 2018-02-05 18:14:02.138 UTC [35] FATAL: database "user-auth" does not exist
pg_1 | 2018-02-05 18:14:02.926 UTC [36] FATAL: database "user-auth" does not exist
pg_1 | 2018-02-05 18:14:04.244 UTC [37] FATAL: database "user-auth" does not exist
pg_1 | 2018-02-05 18:14:04.273 UTC [38] FATAL: database "user-auth" does not exist
pg_1 | 2018-02-05 18:14:04.602 UTC [39] FATAL: database "user-auth" does not exist
pg_1 | 2018-02-05 18:14:04.910 UTC [40] FATAL: database "user-auth" does not exist
pg_1 | 2018-02-05 18:14:05.777 UTC [41] FATAL: database "user-auth" does not exist
pg_1 | 2018-02-05 18:14:05.823 UTC [42] FATAL: database "user-auth" does not exist
pg_1 | 2018-02-05 18:14:05.878 UTC [43] FATAL: database "user-auth" does not exist
pg_1 | 2018-02-05 18:14:06.663 UTC [44] FATAL: database "user-auth" does not exist
pg_1 | 2018-02-05 18:14:06.716 UTC [45] FATAL: database "user-auth" does not exist
pg_1 | 2018-02-05 18:16:32.713 UTC [46] FATAL: database "user-auth" does not exist
pg_1 | 2018-02-05 18:47:04.603 UTC [47] FATAL: database "user-auth" does not exist
pg_1 | 2018-02-05 18:51:34.413 UTC [1] LOG: received smart shutdown request
pg_1 | 2018-02-05 18:51:34.417 UTC [1] LOG: worker process: logical replication launcher (PID 30) exited with exit code 1
pg_1 | 2018-02-05 18:51:34.419 UTC [25] LOG: shutting down
pg_1 | 2018-02-05 18:51:34.434 UTC [1] LOG: database system is shut down
pg_1 | 2018-02-05 19:08:42.934 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432
pg_1 | 2018-02-05 19:08:42.934 UTC [1] LOG: listening on IPv6 address "::", port 5432
pg_1 | 2018-02-05 19:08:42.937 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
pg_1 | 2018-02-05 19:08:42.951 UTC [25] LOG: database system was shut down at 2018-02-05 18:51:34 UTC
pg_1 | 2018-02-05 19:08:42.956 UTC [1] LOG: database system is ready to accept connections
pg_1 | 2018-02-05 19:09:04.316 UTC [32] FATAL: database "user-auth" does not exist
pg_1 | 2018-02-05 19:09:18.081 UTC [33] FATAL: database "user-auth" does not exist
You most probably started the container without the env variables set.
The db was then initialized without user or DB info.
You need to delete the volume and try again.
Credit: https://github.com/docker-library/postgres/issues/453#issuecomment-393939412
You can always initialize scripts for your database before running the container that if even in case you want to add multiple users or create tables initially inside of your container. a basic script would be like :
set -e
psql -v ON_ERROR_STOP=1 --username "$POSTGRES_USER" --dbname "$POSTGRES_DB" <<-EOSQL
CREATE DATABASE database_name;
CREATE USER new_user_name WITH ENCRYPTED PASSWORD 'new_password';
GRANT ALL PRIVILEGES ON DATABASE new_user_name TO database_nam;
EOSQL
and can be saved as a shell file (init_db.sh for example).
Make sure at last to copy the file from your relative directory to the container by adding it to the docker-compose.yml file :
services:
db:
image: postgres:latest
ports:
- '4020:5432'
environment:
- POSTGRES_USER=postgres
- POSTGRES_PASSWORD=postgres
volumes:
- ./init_db.sh:/docker-entrypoint-initdb.d/init_db.sh
In my case, I've already had PostgreSQL working in the background on windows. And when I tried to connect to the docker container, I connected to my windows Postgres. You need to open services.msc and turn off PostreSQL
I was using devcontainer (Python 3 & PostgreSQL) in Visual Studio Code and sqltools.connections settings in devcontainer.json were overriding the configuration in docker-compose.yml.
I changed the settings there too and it worked as expected!
If you are using the Docker application you should delete the existing container and install it again with the command:
docker run --name containerName -p 5432:5432 -e POSTGRES_PASSWORD=postgresql -e POSTGRES_USER=postgresql -e POSTGRES_DB=dbName -d postgres
docker system prune
Adding this removed previous database settings of docker. Then ran again the pipeline after cleanup.