Thank you for your response. I appreciate the clarification regarding the existing behavior of pg_dropcluster --stop. However, I would like to further explain why adding a confirmation prompt or an additional --confirm flag would be a valuable improvement. Current Behavior of pg_dropcluster --stop
- By default, pg_dropcluster --stop does not automatically stop the cluster before deletion. - If the cluster is running, users must manually stop it before executing the deletion. - If attempted while the cluster is active, it results in an error: blessy@blessy-Aspire-Lite-AL15-41:~$ pg_dropcluster 17 custom --stop Warning: stopping the cluster using pg_ctlcluster will mark the systemd unit as failed. Consider using systemctl: sudo systemctl stop postgresql@17-custom Error: You must run this program as the cluster owner (postgres) or root Error: could not stop server, aborting - The user must then manually stop the cluster using: sudo systemctl stop postgresql@17-custom - After stopping, pg_dropcluster --stop can proceed with deletion. Proposed Improvements 1. Modify --stop to Handle Cluster Stopping Automatically Instead of requiring manual intervention, pg_dropcluster --stop could: 1. Attempt to stop the cluster automatically. 2. Prompt a warning before deletion (to prevent accidental loss). Example behavior: sudo pg_dropcluster 17 main --stop Stopping PostgreSQL cluster 17/main... Cluster 17/main stopped successfully. WARNING: You are about to delete the PostgreSQL cluster 17/main. This action is irreversible and will permanently delete all data. Are you sure? (yes/no): _ - This change improves usability by eliminating the need for manual stopping. 2. Introduce a --confirm Flag for Direct Deletion For users who prefer the current behavior, a --confirm flag could be added: sudo pg_dropcluster 17 main --confirm Deleting PostgreSQL cluster 17/main... Removed data directory: /var/lib/postgresql/17/main Removed configuration directory: /etc/postgresql/17/main Removed log file: /var/log/postgresql/postgresql-17-main.log PostgreSQL cluster 17/main deleted successfully. - --stop → Stops cluster (if running) and requires confirmation - --confirm → Skips confirmation and deletes cluster immediately Why This Matters - Eliminates manual steps, making pg_dropcluster --stop more intuitive. - Reduces errors due to forgotten cluster stopping. - Aligns with best practices for preventing unintended data loss. Would your team be open to these improvements? I’d be happy to discuss further or contribute to implementation. Best regards, Akash On Tue, Feb 18, 2025 at 4:20 PM Christoph Berg <m...@debian.org> wrote: > Control: retitle -1 pg_lsclusters should show actually used port > > Re: AKASH > > It would be useful if `pg_lsclusters` could detect and display all > running > > PostgreSQL clusters, including those created manually, for better > > visibility and management. > > That won't really work - there is no cluster name for these, and we > couldn't manage them anyway. > > > When a PostgreSQL cluster is started with a custom port using > > `pg_ctlcluster` (e.g., `-o "-p <port>"`), `pg_lsclusters` reports the > > default port from the `postgresql.conf` file, not the actual port in use > by > > the running instance. > > That has some value, but might be hard to figure out at run time, > especially if the user running pg_lsclusters doesn't have read access > to the postmaster.pid file in the data directory. > > > The `pg_dropcluster --stop` command deletes the PostgreSQL cluster > > immediately without any confirmation prompt or warning. > > That extra safety switch is already there, it's spelled `--stop`. > > Christoph >
