Postgresql que se muere

Franco Catrin L. fcatrin en tuxpan.com
Mie Jul 14 23:29:09 CLT 2010


El mié, 14-07-2010 a las 21:25 -0400, Ricardo Munoz escribió:
> El 14 de julio de 2010 21:01, Gonzalo Diaz <me en gon.cl> escribió:
> 
> [...]
> 
> A propos... independiente del problema original, si un SELECT no "debiera"
> > retornar errores, ¿entonces como la aplicación "debiera" detectar que hubo
> > un problema en la consulta?
> >
> 
> el punto era que en teoria un SELECT no deberia retornar un error de memoria
> si el servicio esta corriendo normalmente ya que si el servicio esta arriba
> es porque tiene la capacidad para servir, en otras palabras, hacer su pega!
> (podria estar lento pero no caerse)

Sí puede retornar un error por falta de memoria.  Basta que la memoria
necesaria para resolver ese select no sea suficiente.

> imaginate un bus del Transantiago que se detenga en plena Alameda (entre dos
> paraderos) solo porque ya no quedan asientos... el bus debe seguir andando
> hasta el proximo paradero, a menos que haya un desperfecto de hardware
> (pinchazo, falla en motor, etc.) algo que no podria ser previsto. tampoco el
> bus debe partir si su conductor considera que no puede llegar hasta el
> proximo paradero...

Si el bus tiene un problema que no puede resolver por si mismo, no podrá
seguir operando y de alguna forma informará a los usuarios,
independiente de que un usuario diga "pero si yo sólo quiero viajar"

-- 
Franco Catrin L.  TUXPAN Software
http://www.tuxpan.com/fcatrin



Más información sobre la lista de distribución Linux