From: | Bear Giles <bear(at)coyotesong(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>, Michael Devogelaere <michael(at)digibel(dot)be>, Justin Clift <justin(at)postgresql(dot)org>, PostgreSQL Hackers Mailing List <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PostgreSQL crashes with Qmail-SQL |
Date: | 2002-01-25 18:01:23 |
Message-ID: | 200201251801.LAA09176@eris.coyotesong.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Caution: I wasted some time running "benchmarks" that proved only
> to be exercising how fast the client could fail. qmail-getpw's
> approach to error handling seems to be (a) don't bother testing for
> very many error conditions (eg, it coredumps on an empty sqlserver
> control file), and (b) if it does detect a failure, exiting with a
> nonzero error code is a sufficient way of reporting it. Error messages
> are for wimps, apparently.
(b) is part of the qmail strategy - qmail is implemented as a set
of independent processes with different owners and rights and they
communicate problems through standard exit codes.
We can agree that it should be more forthcoming with meaningful
help for people setting up the system, but it can't just write an
message to STDOUT because its caller has probably already set up
a pipe to another process - any error message would normally find
itself inserted into the mail queue!
(a), in contrast, is definitely not normal for qmail and is the type
of thing that should be fixed... even if all it does after detecting
a problem is return with a nonzero error code. :-)
Bear
From | Date | Subject | |
---|---|---|---|
Next Message | Bruno Wolff III | 2002-01-25 18:50:07 | Re: PostgreSQL crashes with Qmail-SQL |
Previous Message | Vince Vielhaber | 2002-01-25 17:54:27 | Re: PostgreSQL crashes with Qmail-SQL |