John Iliffe <john.iliffe@iliffe.ca> 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