## Summary When the embedded PostgreSQL is configured to listen on a non-default port via `postgresql['port']`, the container registry database does **not** pick up that port and still tries to connect on `5432`. Since the registry database is now preferred by default (!9330), this causes fresh installs to fail at the registry database migration step. ## Observed failure ``` FATAL: RuntimeError: registry_database_migrations[registry] (registry::database_migrations line 20) had an error: RuntimeError: PostgreSQL did not respond before service checks were exhausted ``` ## Steps to reproduce 1. Set `postgresql['port'] = 5433` in `/etc/gitlab/gitlab.rb` (without setting `registry['database']['port']`). 2. Run `gitlab-ctl reconfigure`. 3. Reconfigure fails on `registry_database_migrations[registry]` because the registry tries to connect on `5432`. ## Root cause `gitlab_rails['db_port']` automatically falls back to `postgresql['port']` (see `Gitlab::Rails.parse_database_settings` in `files/gitlab-cookbooks/gitlab/libraries/gitlab_rails.rb`), so Rails follows the configured port. The registry, however, only derives its database **host** from the PostgreSQL settings in `Registry.parse_database_configuration` (`files/gitlab-cookbooks/gitlab/libraries/registry.rb`). There is no equivalent fallback for the **port** — it stays pinned to the hardcoded attribute default of `5432` (`files/gitlab-cookbooks/registry/attributes/default.rb`). This makes the registry the only DB-connecting component that doesn't follow `postgresql['port']`. ## Proposed fix Have `Registry.parse_database_configuration` fall back to `postgresql['port']` (then the node default) for the registry database port, mirroring how the host is derived and how `gitlab_rails['db_port']` already works. Users can still override explicitly with `registry['database']['port']`. ## Workaround Set the port explicitly in `/etc/gitlab/gitlab.rb`: ```ruby registry['database']['port'] = 5433 ```