John Iliffe <john.iliffe@xxxxxxxxx> writes: > Now, running as user postgres I try and start as stated in the manual > postgres -D /usr/pgsql_tablespaces > The result is: > [postgres@prod04 postgresql-9.6.2]$ postgres -D /usr/pgsql_tablespaces > LOG: could not bind IPv4 socket: Cannot assign requested address > HINT: Is another postmaster already running on port 5432? If not, wait a > few seconds and retry. > LOG: database system was shut down at 2017-03-07 22:22:57 EST > LOG: MultiXact member wraparound protections are now enabled > LOG: database system is ready to accept connections > LOG: autovacuum launcher started To clarify: the postmaster *is* starting here. It failed to bind to the IPv4 port 5432, but it must have succeeded in binding to at least one other port (IPv6 and/or a Unix socket), else it would have stopped and you'd have not seen the last four log lines. It might be helpful to check with lsof to see what the postmaster process has open after you do this. > I checked with lsof and there is no process bound to socket 5432. There is > no entry in /var/run for a socket related to postgresql. With the default configure options you used, the postmaster would have put its Unix socket file into /tmp, not /var/run. I wonder whether your problem is that you're trying to connect to it with distro-supplied psql+libpq that expects to find the Unix socket in /var/run. > One thing that I haven't been able to find any the log files. Where are they > normally stored? They seem to be showing up on postmaster's stderr (ie, your terminal) which again is the vanilla-configuration default if you didn't do anything to edit the postgresql.conf settings. I suspect that you're used to the behavior of a vendor-configured postgres package and have not taken the steps needed to make a build from source behave the same way. Recommend looking into what patches the vendor package applies and what configure options are used. Having said all that, it's very un-obvious why you're failing to bind to the IPv4 socket. If there's no active postmaster on the machine, that should be free. I could believe SELinux blocking it, except that the targeted SELinux policy shouldn't constrain a manually-started postmaster at all --- not to mention that you're in permissive mode. Seems like the answer must be elsewhere. You didn't mention what platform you're on, but the reference to SELinux makes me think it's probably Red Hat. A bit of digging in RH's support portal turns up a few mentions of kernel bugs causing unexpected EADDRNOTAVAIL errors, which matches this symptom ... so how up-to-date is this server? regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
