On Jul 15, 2010, at 4:59 PM, Franco Catrin L. wrote:
El jue, 15-07-2010 a las 16:19 -0400, Aldrin Martoq escribió:
Las capas de abstracción no son para protegernos de los errores, son para
*solucionar un problema*. Esto implica que son buenas para cierto ámbito (no
para todas) pues están
El Wed, 14 Jul 2010 17:08:24 -0400
Alvaro Herrera alvhe...@alvh.no-ip.org escribió:
(¿Cuántos de aquí usan memoria ECC en sus servidores de
datos?)
En mi caso NO es asumible no tener ECC en casi ningún servidor
productivo, por estúpido y sencillo que sea este. Usar
servidores de datos
Excerpts from AngelD's message of vie jul 16 05:37:27 -0400 2010:
El Wed, 14 Jul 2010 17:08:24 -0400
Alvaro Herrera alvhe...@alvh.no-ip.org escribió:
(¿Cuántos de aquí usan memoria ECC en sus servidores de
datos?)
En mi caso NO es asumible no tener ECC en casi ningún servidor
El mié, 14-07-2010 a las 17:16 -0400, Aldrin Martoq escribió:
On Jul 14, 2010, at 3:14 PM, Franco Catrin L. wrote:
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:
On Thu, 2010-07-15 at 10:03 -0400, Franco Catrin L. wrote:
El mié, 14-07-2010 a las 17:16 -0400, Aldrin Martoq escribió:
On Jul 14, 2010, at 3:14 PM, Franco Catrin L. wrote:
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.
On Jul 15, 2010, at 10:03 AM, Franco Catrin L. wrote:
El mié, 14-07-2010 a las 17:16 -0400, Aldrin Martoq escribió:
On Jul 14, 2010, at 3:14 PM, Franco Catrin L. wrote:
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
El jue, 15-07-2010 a las 13:02 -0400, Aldrin Martoq escribió:
On Jul 15, 2010, at 10:03 AM, Franco Catrin L. wrote:
El mié, 14-07-2010 a las 17:16 -0400, Aldrin Martoq escribió:
On Jul 14, 2010, at 3:14 PM, Franco Catrin L. wrote:
Eso es lo que se ve por fuera, pero el día en que inventen
On Jul 15, 2010, at 3:15 PM, Franco Catrin L. wrote:
El jue, 15-07-2010 a las 13:02 -0400, Aldrin Martoq escribió:
On Jul 15, 2010, at 10:03 AM, Franco Catrin L. wrote:
Mi mirada al documento es respecto a cómo las abstracciones pueden jugar
en contra cuando no sabes qué está pasando realmente
El jue, 15-07-2010 a las 16:19 -0400, Aldrin Martoq escribió:
On Jul 15, 2010, at 3:15 PM, Franco Catrin L. wrote:
El jue, 15-07-2010 a las 13:02 -0400, Aldrin Martoq escribió:
On Jul 15, 2010, at 10:03 AM, Franco Catrin L. wrote:
Mi mirada al documento es respecto a cómo las abstracciones
Excerpts from Ricardo Munoz's message of mar jul 13 16:51:29 -0400 2010:
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
On Tue, 2010-07-13 at 17:46 -0400, Franco Catrin L. wrote:
hmm... insisto que ningun motor de base de datos decente deberia retornar un
mensaje de error de memoria como resultado de un SELECT
Por qué no?
A mi me parece razonable que el motor tire un error de falta de
memoria...
El 14 de julio de 2010 15:14, Franco Catrin L. fcat...@tuxpan.comescribió:
El mar, 13-07-2010 a las 18:14 -0400, Ricardo Munoz escribió:
El 13 de julio de 2010 17:46, Franco Catrin L. fcat...@tuxpan.com
escribió:
El mar, 13-07-2010 a las 17:28 -0400, Ricardo Munoz escribió:
[...]
Hola!
2010/7/14 Gonzalo Diaz m...@gon.cl
Si un SELECT no pudiera retornar errores de memoria, ¿para que diablos
habrán inventado el sistema de excepciones en postgresql?
Las excepciones van dentro del codigo de PL/SQL. En este caso especifico, el
motor de DB es el que esta teniendo el
El mié, 14-07-2010 a las 15:31 -0400, Gonzalo Diaz escribió:
El 14 de julio de 2010 15:14, Franco Catrin L. fcat...@tuxpan.comescribió:
El mar, 13-07-2010 a las 18:14 -0400, Ricardo Munoz escribió:
El 13 de julio de 2010 17:46, Franco Catrin L. fcat...@tuxpan.com
escribió:
El mar,
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
Excerpts from Franco Catrin L.'s message of mié jul 14 15:45:15 -0400 2010:
El mié, 14-07-2010 a las 15:31 -0400, Gonzalo Diaz escribió:
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
El 14 de julio de 2010 15:57, Marcos Ramirez mramir...@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
El mié, 14-07-2010 a las 15:57 -0400, Marcos Ramirez 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
Excerpts from Ricardo Munoz's message of mié jul 14 16:51:26 -0400 2010:
El 14 de julio de 2010 15:57, Marcos Ramirez mramir...@armada.cl escribió:
Por seguir tu linea: si se considera aceptable que el motor entregue
un error al hacer un [simple] select, ¿que deberia hacer la aplicacion?
Excerpts from Franco Catrin L.'s message of mié jul 14 17:05:43 -0400 2010:
Parece que todos perdimos el punto hace rato.
Viendo el error que aparece en el post original, no me es evidente que
PostgreSQL se haya ido al suelo, también puede ser un error reportado
por el sistema de
On Jul 14, 2010, at 3:14 PM, Franco Catrin L. wrote:
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
Yo difiero de este pensamiento. La capa extra (en
Excerpts from Aldrin Martoq's message of mié jul 14 17:16:51 -0400 2010:
Yo también insisto que es un bug de postgresql. Para este ejemplo en
particular, la base de datos puede hacer un montón de cosas como dado que es
un problema de memoría reportar qué cosa generó el error (en particular,
On Wed, 2010-07-14 at 17:05 -0400, Franco Catrin L. wrote:
Parece que todos perdimos el punto hace rato.
Me recuerda los dias mas brillantes de esta lista :)
Viendo el error que aparece en el post original, no me es evidente que
PostgreSQL se haya ido al suelo, también puede ser un error
On Jul 14, 2010, at 5:20 PM, Alvaro Herrera wrote:
Excerpts from Aldrin Martoq's message of mié jul 14 17:16:51 -0400 2010:
Yo también insisto que es un bug de postgresql. Para este ejemplo en
particular, la base de datos puede hacer un montón de cosas como dado que es
un problema de
Para volver a la discusión original, lo que yo haría:
1.- Probar la memoria con memtest86+ o similar
2.- Actualizar a las últimas versiones de PostgreSQL servidor y cliente, de
ser posible
3.- Investigar si existe un bug relacionado
Suerte
2010/7/14 Aldrin Martoq amar...@dcc.uchile.cl
On Jul
quizas posgtres no esta consumiendo toda la memoria, sino la que queda
disponible... y ese es su limite..
2010/7/14 Juan C. Olivares juan...@juancri.com
Para volver a la discusión original, lo que yo haría:
1.- Probar la memoria con memtest86+ o similar
2.- Actualizar a las últimas versiones
On 13/07/10 02:21, Andres Junge wrote:
Hola
Tenemos un servidor con Asterisk el cual registra todas las llamadas que
pasan por el en un servidor postgresql. Todo andaba bien hasta que
derrepente el postgresql dejo de atender algunas consultas. Por ejemplo
si le envio:
asterisk= SELECT
On 13/07/10 02:21, Andres Junge wrote:
Hola
Tenemos un servidor con Asterisk el cual registra todas las llamadas que
pasan por el en un servidor postgresql. Todo andaba bien hasta que
derrepente el postgresql dejo de atender algunas consultas. Por ejemplo
si le envio:
asterisk=
On 14/07/10 18:29, Eduardo Silva wrote:
On 13/07/10 02:21, Andres Junge wrote:
Hola
Tenemos un servidor con Asterisk el cual registra todas las llamadas que
pasan por el en un servidor postgresql. Todo andaba bien hasta que
derrepente el postgresql dejo de atender algunas consultas.
El 14 de julio de 2010 18:32, Enrique Herrera Noya
quique...@gmail.comescribió:
On 14/07/10 18:29, Eduardo Silva wrote:
On 13/07/10 02:21, Andres Junge wrote:
Hola
Tenemos un servidor con Asterisk el cual registra todas las llamadas
que
pasan por el en un servidor postgresql. Todo
El 14 de julio de 2010 21:25, Ricardo Munoz rmu...@tux.cl escribió:
El 14 de julio de 2010 21:01, Gonzalo Diaz m...@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
El mié, 14-07-2010 a las 21:25 -0400, Ricardo Munoz escribió:
El 14 de julio de 2010 21:01, Gonzalo Diaz m...@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
Andres,
creo que es tiempo de realizar un tunning a tu servidor (sistema operativo)
y tambien a la configuración de postgresql en postgresql.conf según los
recursos de hardware que tengas.
2010/7/13 Andres Junge aju...@totexa.cl:
Hola
Tenemos un servidor con Asterisk el cual registra todas las
2010/7/13 Andres Junge aju...@totexa.cl
Hola
Tenemos un servidor con Asterisk el cual registra todas las llamadas que
pasan por el en un servidor postgresql. Todo andaba bien hasta que
derrepente el postgresql dejo de atender algunas consultas. Por ejemplo
si le envio:
asterisk= SELECT
Hola
Gracias por contestar. Que cosas podria tunear por ejemplo?
Saludos
Andres
El mar, 13-07-2010 a las 12:07 -0500, Moises Alberto Lindo Gutarra
escribió:
Andres,
creo que es tiempo de realizar un tunning a tu servidor (sistema operativo)
y tambien a la configuración de postgresql en
El mar, 13-07-2010 a las 13:20 -0400, Ricardo Munoz escribió:
2010/7/13 Andres Junge aju...@totexa.cl
Hola
Tenemos un servidor con Asterisk el cual registra todas las llamadas que
pasan por el en un servidor postgresql. Todo andaba bien hasta que
derrepente el postgresql dejo de atender
El Tue, 13-07-2010 a las 14:27 -0400, Andres Junge escribió:
Hola
Gracias por contestar. Que cosas podria tunear por ejemplo?
Parte testeando la memoria de la maquina :)
Saludos
Andres
El mar, 13-07-2010 a las 12:07 -0500, Moises Alberto Lindo Gutarra
escribió:
Andres,
creo que
2010/7/13 Marcelo Espinosa Alliende marc...@ubiobio.cl
El Tue, 13-07-2010 a las 14:27 -0400, Andres Junge escribió:
Hola
Gracias por contestar. Que cosas podria tunear por ejemplo?
Parte testeando la memoria de la maquina :)
Habia un truquito usando el valor de maintenance_work_mem y
2010/7/13 Andres Junge aju...@totexa.cl:
Hola
Tenemos un servidor con Asterisk el cual registra todas las llamadas que
pasan por el en un servidor postgresql. Todo andaba bien hasta que
derrepente el postgresql dejo de atender algunas consultas. Por ejemplo
si le envio:
asterisk= SELECT
On Jul 13, 2010, at 3:24 PM, Rodrigo Ramirez Norambuena wrote:
2010/7/13 Andres Junge aju...@totexa.cl:
Tenemos un servidor con Asterisk el cual registra todas las llamadas que
pasan por el en un servidor postgresql. Todo andaba bien hasta que
derrepente el postgresql dejo de atender algunas
El Tue, 13 Jul 2010 02:21:00 -0400
Andres Junge aju...@totexa.cl escribió:
Hola
Tenemos un servidor con Asterisk el cual registra todas las llamadas
que pasan por el en un servidor postgresql. Todo andaba bien hasta que
derrepente el postgresql dejo de atender algunas consultas. Por
ejemplo
El 13 de julio de 2010 16:24, AngelD ang...@froga.net escribió:
El Tue, 13 Jul 2010 02:21:00 -0400
Andres Junge aju...@totexa.cl escribió:
Hola
Tenemos un servidor con Asterisk el cual registra todas las llamadas
que pasan por el en un servidor postgresql. Todo andaba bien hasta que
Hola!
2010/7/13 Ricardo Munoz rmu...@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
El mar, 13-07-2010 a las 17:28 -0400, Ricardo Munoz escribió:
[...]
hmm... insisto que ningun motor de base de datos decente deberia retornar un
mensaje de error de memoria como resultado de un SELECT
Por qué no?
A mi me parece razonable que el motor tire un error de falta de
memoria...
El 13 de julio de 2010 17:46, Franco Catrin L. fcat...@tuxpan.comescribió:
El mar, 13-07-2010 a las 17:28 -0400, Ricardo Munoz escribió:
[...]
hmm... insisto que ningun motor de base de datos decente deberia retornar
un
mensaje de error de memoria como resultado de un SELECT
Por
Hola!
2010/7/13 Ricardo Munoz rmu...@tux.cl
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()...
Como dije, puede
@listas.inf.utfsm.cl
Subject:
Re: Postgresql que se muere
Date:
13/07/2010 13:51
El 13 de julio de 2010 16:24, AngelD ang...@froga.net escribió:
El Tue, 13 Jul 2010 02:21:00 -0400
Andres Junge aju...@totexa.cl escribió:
Hola
Excerpts from Andres Junge's message of mar jul 13 02:21:00 -0400 2010:
Hola
Tenemos un servidor con Asterisk el cual registra todas las llamadas que
pasan por el en un servidor postgresql. Todo andaba bien hasta que
derrepente el postgresql dejo de atender algunas consultas. Por ejemplo
si
48 matches
Mail list logo
