On Wed, Nov 17, 2010 at 19:57, Bruce Momjian <br...@momjian.us> wrote: > Magnus Hagander wrote: >> On Wed, Nov 17, 2010 at 19:50, Bruce Momjian <br...@momjian.us> wrote: >> > Magnus Hagander wrote: >> >> Does this actually solve the *problem*, though? The problem is not >> >> what is reported ?on stdout/stderr, the problem is that the net result >> >> is that the server is reported as not started (by the service control >> >> manager) when it actually *is* started. In this case, stderr doesn't >> >> even go anywhere. What happens if you *don't* Ctrl-C it? >> > >> > I was just going to post on that. ?:-) ?Right now, it prints the FATAL >> > and keeps printing 60 times, then says not running. ?Should we just exit >> > on FATAL and output a special exit string, or say running? >> >> >From the perspective of the service control manager, it should say >> running. That might break other scenarios though, but i'm not sure - I >> think we can safely say the server is running when we try to log in >> and get a password failure. > > That was another part of the discussion. Right now we report any FATAL, > so it might be a password problem, or something else, and it seems doing > all FATALs is the best idea because it will catch any other cases like > this. > > Is FATAL, in general, enough to conclude the server is running?
No - specifically, we will send FATAL when "the database system is starting up", which is exactly the one we want to *avoid*. I think we should only exclude the password case. I guess we could also do all fatal *except* <list>, but that seems more fragile. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
