Thank you for your response. You raise a valid point about updating the config file instead of using command-line options.
One genuine use case we encounter is during database failover testing and recovery drills. We need to temporarily spin up secondary instances of existing clusters on different ports to verify our failover procedures without modifying the primary configuration files. During these exercises, we: - Clone the data directory of a production cluster - Start the clone with a different port via command-line options - Test failover mechanisms and synchronization procedures - Shut down the temporary instance when testing completes This allows us to validate our disaster recovery procedures without disrupting our production configuration or permanently altering postgresql.conf files. Since these are temporary instances, running them outside systemd helps keep our production services untouched and avoids unnecessary persistent configuration changes. The challenge we face is that pg_lsclusters reports only the default port from,postgresql.conf not the actual port in use when a cluster is started with a custom port via pg_ctlcluster.My workaround script addresses this immediate need by providing accurate port information specifically for PostgreSQL instances, making our testing workflow more efficient. Currently, the script requires sudo privileges to run properly. I'm also interested in suggestions on how to modify it to work for normal users without elevated permissions, if possible. Best regards, Akash On Wed, Mar 19, 2025 at 4:37 PM Christoph Berg <m...@debian.org> wrote: > Re: AKASH > > I have been exploring an issue where pg_lsclusters reports the default > port > > from postgresql.conf, rather than the actual port in use when a > PostgreSQL > > cluster is started with a custom port using pg_ctlcluster (e.g., -o "-p < > > port>"). > > Can you explain why you need to use these command line options and > aren't just updating the config? This usage of pg_ctlcluster will also > bypass starting the cluster as systemd service which isn't desirable. > > Christoph >
