Re: PostgreSQL crashes with Qmail-SQL - Mailing list pgsql-hackers

From Jan Wieck
Subject Re: PostgreSQL crashes with Qmail-SQL
Date
Msg-id 200201241914.g0OJEjP17718@saturn.janwieck.net
Whole thread Raw
In response to Re: PostgreSQL crashes with Qmail-SQL  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: PostgreSQL crashes with Qmail-SQL  (Michael Devogelaere <michael@digibel.be>)
List pgsql-hackers
Tom Lane wrote:
> Michael Devogelaere <michael@digibel.be> writes:
> > On Thu, Jan 24, 2002 at 01:11:39PM -0500, Tom Lane wrote:
> >> What showed up in the postmaster log when this happened?  I would like
> >> *exact* error message texts, not approximations.
> > Nothing. I disabled all logging since the database responded too slowly
> > with logging turned on. So i cannot help you on this.
>
> If you're not going to be cooperative, then I don't see how you expect
> us to fix the problem.
>
> FWIW, I don't believe for a moment that /dev/null'ing the postmaster log
> improves performance measurably.  I've done plenty of profiling in my
> time, and never seen any indication that it's an issue; at least not at
> the default verbosity level.
>
> >> What happened when you tried to connect with psql?  Again, exact, not
> >> approximate.
> > psql: connectDBStart() -- connect() failed: No such file or directory
> >  Is the postmaster running locally
> >  and accepting connection on Unix socket ...
>
> No such file??  Hard to believe that that could happen while the
> postmaster was still running.  Unless something else had decided to
> delete the socket file from /tmp.  The postmaster certainly would not
> do it.
   Haven't  there been some over enthusiastic cleanup scripts in   some Linux  distro's,  that  removed  the  socket
from /tmp   because of it's age?
 
   Anyway, so in summary:
   1.  The  test case was the *well known* MySQL favorite suite;       Simple  one-table  read-only  access  with
myriads  of       connect's.
 
   2.  The  *well  known* fact that PostgreSQL out of the box is       not configured for production was ignored.
   3.  Any possibility to track down the  reasons  for  problems       was disabled.
   4.  Instead  of investigating what the problem is, PostgreSQL       was reported to *Crash*.
   It cannot get any more obvious.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com



pgsql-hackers by date:

Previous
From: "Mikheev, Vadim"
Date:
Subject: Re: Savepoints
Next
From: Bruce Momjian
Date:
Subject: Re: Savepoints