Postgresql que se muere

[Ricardo Munoz]

El 13 de julio de 2010 17:11, Juan Inostroza <jci en codemonkey.cl> escribió:

> Hola!
>
> 2010/7/13 Ricardo Munoz <rmunoz en tux.cl>
>
>
> > da para pensar como tanta gente hizo la pega (buscar en Google) del autor
> > del primer mail y/o respondieron a la rapida y mal. cualquier usuario de
> un
> > motor de base de datos debe saber que
> >
>
> ...
>
>
> > - el resultado de un SELECT nunca puede ser un mensaje de error de
> memoria
> >
>
>
> > - el resultado de un servicio mal optimizado nunca puede ser un mensaje
> de
> > error de memoria durante su operacion (instruccion SELECT), sino solo al
> > momento de subir el servicio
> >
> > por lo tanto, la unica explicacion logica al problema es que
> >
> > - se trata de un bug de Postgres, donde la solucion es actualizar ojala
> > usando el metodo ofrecido por la distro de Linux
> >
>
> No necesariamente.
>
> Hay algunos "problemillas" que he pillado ultimamente en MySQL que a veces
> tiran a hacer consumo excesivo de memoria (como algunos subselects). Y
> tecnicamente, se arreglan haciendo algunos ajustes al mismo query.
>

aunque el thread es acerca de Postgres, pero ni siquiera en MySQL aparece un
error de memoria como resultado de una query... si la query usa mucha
memoria, el servicio se pondra "lento" o incluso se podria "congelar" hasta
que termine de procesar la query... pero nunca quedar "sin memoria"...

 > - se trata de un error de hardware (memoria o disco), donde la solucion
> es
> > reemplazar el hardware malo o cambiar el servicio a otra maquina
> >
>
> Me gustaria ver los valores de los parametros que mande antes. Quizas
> podrian decir, o bien que es el mismo bug (un rapido googleo) o bien que la
> tabla ni siquiera esta optimizada.
>

hmm... insisto que ningun motor de base de datos decente deberia retornar un
mensaje de error de memoria como resultado de un SELECT....

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