On Tue, May 5, 2015 at 03:36:07PM -0400, Peter Eisentraut wrote: > > BTW, why are we advocating postgres binary use at all? AFAICS the main > > postgres (or postmaster) uses are (i) startup script (which also > > advocate for 'pg_ctl -w') and (ii) disaster/debugging purposes. None of > > those use cases are intended for general users. Let's make it simple and > > drop 'postgres' line. > > 1. I like copying and pasting the "postgres" line during development. > That's not a reason to keep it, necessarily. > > 2. If you're saying, most people shouldn't run postgres directly, then > most people also shouldn't run initdb directly. This message will > mainly be seen either by developers or testers or tutorial users or > do-it-yourselfers. In which case knowing the functionality of the > postgres program is valid. > > 3. It's not clear that pg_ctl is necessarily the best way to start the > server. With things like systemd, launchd, supervisord that like to > manage the daemons directly, using postgres directly might be the > preferable choice.
Well, my initial suggestion was just to recommend pg_ctl first, rather than remove the postgres binary line, so I assume you are fine with doing that. I think we should be looking at who is running initdb manually, then decide what is the best recommendation. While developers or testers are certainly running initdb directly, I think our largest group of initdb-directly users are those installing multiple clusters on a single server. Frankly, I am not sure how they are starting the server as the /etc/init.d startup files don't handle multiple clusters well, and I have never seen instructions on how multi-cluster users are supposed to set things up. I assume they are copying the existing init.d file with a new name and modifying PGDATA and maybe the port number, then doing 'service ... start' or something like that. I doubt we want initdb to recommend that. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
