Postgresql que se muere

[Gonzalo Diaz]

El 14 de julio de 2010 21:25, Ricardo Munoz <rmunoz en tux.cl> 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)
>
> 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...
>
> --
> Ricardo Mun~oz A.
> http://www.tux.cl
>


Entiendo la analogía, pero la considero un poco rara.

Desde el punto de vista de como informar "la micro va llena" al usuario,
porque al final el resultado es que no podrá subir, pero si la micro "no
informa" (visualmente en este caso a través de la ventana de la micro) que
está llena, el usuario nunca va a saber porque no pudo subir a la micro.

Más raro me parecería tener la certeza que mis tablas están llenas de datos
y mi SELECT retorne cero tuplas sin informar de un error. Y rayaría en lo
esotérico encontrar el error de memoria.


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Atentamente, Gonzalo Díaz Cruz
Estudiante Ingeniería de Ejecución en Computación e Informática
Universidad de Santiago de Chile
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

http://blog.gon.cl/
http://twitter.com/sir_gon
http://flickr.com/photos/sir_gon