Postgresql que se muere

[Alvaro Herrera]

Excerpts from Ricardo Munoz's message of mié jul 14 16:51:26 -0400 2010:
> El 14 de julio de 2010 15:57, Marcos Ramirez <mramireza en armada.cl> escribió:

> > Por seguir tu linea: si se considera "aceptable" que el motor entregue
> > un error al hacer un [simple] select, ¿que deberia hacer la aplicacion?
> > ¿reintentar hasta que funcione, reemplazar la funcionalidad del motor
> > por una propia, otra?
> >
> > Si yo estuviera frente a esa disyuntiva, me deshago del motor, o lo
> > cambio por otro mas confiable. O simplemente que la aplicacion maneje
> > los archivos directamente.
> 
> exactamente ese era mi punto cuando puse que un SELECT no deberia retornar
> un error de memoria... de que sirve el motor de base de datos si no me
> asegura un correcto funcionamiento bajo condiciones normales (hw sin
> problemas)?

Huh.

Lo correcto es que la aplicación registre el error, le de un mensaje al
usuario "lo siento, no podemos atenderlo en este momento, intente de
nuevo más tarde", y le mande un mensaje al admin para que le eche una
mirada.  Si es un bug en la aplicación, se corrige; si es un problema en
los datos, se agrega una nueva restricción (constraint).  Si es un
problema de hardware, se cambia el servidor.  Y así.  Pero es totalmente
responsabilidad de la aplicación asegurarse que actúa sano en casos
inesperados.

Me acuerdo que en un proyecto en que trabajaba en una empresa, el módulo
que recibía el código SQL para ejecutar mandaba cualquier excepción por
correo.  Recibimos dos o tres correos durante el período de producción
en que yo estuve en la empresa (obviamente cientos de ellos durante el
desarrollo y la marcha blanca), si mal no recuerdo uno de ellos era un
problema corregible y los restantes eran "mala suerte", "cosas de la
vida" o eventos totalmente inesperados.

> y si el sysadmin se condorea con los distintos parametros de
> configuracion, el servicio simplemente no deberia activarse a menos que
> pueda asegurar un correcto funcionamiento (lento pero seguro).

Las fallas siempre ocurren.  No estar preparado para ellas es síntoma de
mala ingeniería.  Aún cuando tengas el mejor hardware del mundo y el
sistema mejor afinado del mundo, te pueden caer rayos cósmicos en
cualquier momento en una celda de la RAM y cambiarte un bit en los
datos.  (¿Cuántos de aquí usan memoria ECC en sus servidores de datos?)