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 <[email protected]> Documento PUBLICO
