Postgresql que se muere

[Marcos Ramirez]

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. 

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

Saludos

-- 
Marcos Ramirez <mramireza en armada.cl>

Documento PUBLICO