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")));
                }