Someone (possibly me) foolishly reduced the response for failing

to create a TCP/IP socket from FATAL to LOG.  This was unwise;
historically we have expected socket conflicts to abort postmaster
startup.  Conflicts on port numbers with another postmaster can only
be detected reliably at the TCP socket level.

diff --git a/src/backend/postmaster/postmaster.c b/src/backend/postmaster/postmaster.c
index 2cb660e2f52577bd953e31e13b9cab140ea9289a..4fc3840f44bef0e8233424f6e031823ea408e1e6 100644 (file)
--- a/src/backend/postmaster/postmaster.c
+++ b/src/backend/postmaster/postmaster.c
@@ -37,7 +37,7 @@
  *
  *
  * IDENTIFICATION
- *   $Header: /cvsroot/pgsql/src/backend/postmaster/postmaster.c,v 1.344 2003/09/11 18:30:39 momjian Exp $
+ *   $Header: /cvsroot/pgsql/src/backend/postmaster/postmaster.c,v 1.345 2003/09/12 19:33:59 tgl Exp $
  *
  * NOTES
  *
@@ -753,7 +753,7 @@ PostmasterMain(int argc, char *argv[])
                                          UnixSocketDir,
                                          ListenSocket, MAXLISTEN);
                if (status != STATUS_OK)
-                   ereport(LOG,
+                   ereport(FATAL,
                     (errmsg("could not create listen socket for \"%s\"",
                             curhost)));
                if (endptr)
@@ -772,7 +772,7 @@ PostmasterMain(int argc, char *argv[])
                                      UnixSocketDir,
                                      ListenSocket, MAXLISTEN);
            if (status != STATUS_OK)
-               ereport(LOG,
+               ereport(FATAL,
                      (errmsg("could not create TCP/IP listen socket")));
        }