Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Abort if standby.signal is found #83

Open
ElDavoo opened this issue Jan 14, 2025 · 1 comment
Open

Abort if standby.signal is found #83

ElDavoo opened this issue Jan 14, 2025 · 1 comment

Comments

@ElDavoo
Copy link

ElDavoo commented Jan 14, 2025

I'm testing with the standby DBs before trying the main one and this happens:

db-delay-1  | Determining our own initdb arguments
db-delay-1  | ------------------------------------
db-delay-1  | 2025-01-14 12:13:35.535 UTC [36] LOG:  database system was shut down in recovery at 2025-01-14 12:11:34 UTC
db-delay-1  | 2025-01-14 12:13:35.535 UTC [36] FATAL:  standby mode is not supported by single-user servers
db-delay-1 exited with code 0

The script should handle the existence of standby.signal in some way.

@ElDavoo
Copy link
Author

ElDavoo commented Jan 14, 2025

Apparently (well it's obvious now that I think about it), upgrading creates a new DB cluster, regenerating the system identifier, which needs to be the same between primary and standby.
So, this container should say something like "Hey, you can't do this, recreate the hot standby"
If you remove standby.signal, the migration works, but after that you'll get
FATAL: database system identifier differs between the primary and standby

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant