From: | "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org> |
---|---|
To: | Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> |
Cc: | "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-advocacy(at)postgresql(dot)org, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL www <pgsql-www(at)postgresql(dot)org> |
Subject: | Re: [pgsql-advocacy] Server unreliability |
Date: | 2004-09-29 23:24:31 |
Message-ID: | 20040929202326.Q3407@ganymede.hub.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-advocacy pgsql-www |
On Wed, 29 Sep 2004, Alvaro Herrera wrote:
> about pg_query not getting a good connection or similar problems.
> Isn't normal advice to check return codes before even trying to use the
> connections? Why isn't this done in the main postgresql.org code, where
> anyone can see it, is beyond me. Of course the solution to the
> underlying problem is to restart the Postgres server, but why should we
> inform the user that Postgres' own database server is down, in the worst
> possible way?
Just curious here, but when/where? We haven't had a database issue in
quite awhile that *I'm* aware of ... in fact, the whole web site is
static, generated periodically from .php files, so that the mirrors can
pick things up properly, so there should never be a 'cannot connect to
database' issue, since there are no connections to the database being made
...
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664
From | Date | Subject | |
---|---|---|---|
Next Message | Marc G. Fournier | 2004-09-29 23:35:51 | Re: [pgsql-advocacy] Server unreliability |
Previous Message | Josh Berkus | 2004-09-29 23:13:20 | Re: Server unreliability |
From | Date | Subject | |
---|---|---|---|
Next Message | Marc G. Fournier | 2004-09-29 23:35:51 | Re: [pgsql-advocacy] Server unreliability |
Previous Message | Josh Berkus | 2004-09-29 23:13:20 | Re: Server unreliability |