Re: PostgreSQL crashes with Qmail-SQL
От | Michael Devogelaere |
---|---|
Тема | Re: PostgreSQL crashes with Qmail-SQL |
Дата | |
Msg-id | 20020125021615.A5776@digibel.be обсуждение исходный текст |
Ответ на | Re: PostgreSQL crashes with Qmail-SQL (Jan Wieck <janwieck@yahoo.com>) |
Ответы |
Re: PostgreSQL crashes with Qmail-SQL
(Jan Wieck <janwieck@yahoo.com>)
|
Список | 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.
В списке pgsql-hackers по дате отправления: