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

> > > 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?
The system was running in single user mode when running the tests (i think
i already mentioned that). This was done to prevent the results from
being influenced by daily/hourly cronjobs such as logrotate. The symptom
you're probably referring too is the daily run of 'tmpwatch':
- since cron was disabled, tmpwatch didn't run
- tmpwatch cleans empty directories and regular files. Sockets are leaved unchanged.
> 
>     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.
That's correct: qmail-getpw is called myriads of times: each time a
mail needs to be delivered locally. I don't care about whether this
favours one database or not: it's what happens on a busy mailserver.
> 
>     2.  The  *well  known* fact that PostgreSQL out of the box is
>         not configured for production was ignored.
From http://qmail-sql.digibel.be/testing.html:  The first testround uses the database-configurations as shipped by Red
Hat: postgresql  7.1.3  and  mysql 3.23.41. No additional performance  tuning  was  performed. 
 

IMHO i didn't ignore the lack of tuning. And i DO want to tune it, but
it seemed fair to me to start the test with the default configuration as
shipped by RedHat and then investigate the results of different tunings.
But the next tests were skipped since postgresql crashed.
> 
>     3.  Any possibility to track down the  reasons  for  problems
>         was disabled.
My first idea was to log connects,queries and disconnects: i imagine most
database-admins turned logging on in their databases. With mysql it runs
these things when you turn on 'log=/var/log/..'. I configured postgresql
to log the same and ran 1 'qmail-getpw' testrun:
- with logging: 112 seconds.
- without logging: 32 seconds.
I suspect this has to with the fact that i configured postgresql to log
to syslog. Don't blame me for this: it's the way RedHat ships postgresql.
To make things fair i disabled logging on both databases (mysql-
performance is not affected by logging, but it doesn't use syslog). This
also excluded vital debug-messages. Frankly: i didn't expect postgresql
to crash but i'll turn them on a next time.
> 
>     4.  Instead  of investigating what the problem is, PostgreSQL
>         was reported to *Crash*.
Yes: it *crashed*. Since i disabled all debugging i cannot help you
with investigating this problem. I hope i won't get the death penalty
for this ;)
> 
>     It cannot get any more obvious.
Please elaborate.

Michael.