Postgresql que se muere

[Ricardo Munoz]

El 14 de julio de 2010 15:57, Marcos Ramirez <mramireza en armada.cl> escribió:

> On Wed, 2010-07-14 at 15:45 -0400, Franco Catrin L. wrote:
> > El mié, 14-07-2010 a las 15:31 -0400, Gonzalo Diaz escribió:
>
> > > > > eso quiere decir que tendrias que poner mas memoria a tu servidor
> por
> > > > cada
> > > > > n-cantidad de nuevos registros que le agregas a la base de datos?
> eso no
> > > > > tiene sentido... y fijate que el error se produjo con un simple
> SELECT
> > > > > COUNT()...
> > > >
> > > > Eso es lo que se ve por fuera, pero el día en que inventen un SELECT
> que
> > > > ocupe cero bytes está lejos aún.
> > > >
> > > > Lectura recomendada:
> > > > http://www.joelonsoftware.com/articles/LeakyAbstractions.html
> > > >
> > > > ... y por supuesto, la explicación detallada de Alvaro sobre lo que
> > > > sucede behind the scenes.
> > > >
> > > Si un SELECT no pudiera retornar errores de memoria, ¿para que diablos
> > > habrán inventado el sistema de excepciones en postgresql?
> > >
> > > Cabe recordar que un SP se puede programar varios lenguajes ajenos.
> >
> > Eso es lo que se ve por fuera, pero el día en que inventen un sistema de
> > excepciones que ocupe cero bytes está lejos aún.
>
> Estas perdiendo el punto. No se trata de cuantos bytes ocupe el
> select/procedimiento o de si un procedimiento puede o no arrojar una
> excepcion; sino que el motor no traspase errores que son inmanejables a
> nivel de aplicacion.
>
> 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)? 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).

Distinto es el caso cuando hay un problema subyacente, como error de
> memoria, disco corrupto o similar, en cuyo caso, se cambia la maquina.
>

exacto.

-- 
Ricardo Mun~oz A.
http://www.tux.cl