Re: fatal out of shared memory postgres

Excerpts from Rensi Arteaga Copari's message of lun sep 27 11:43:34 -0400 2010:
> El 27/09/2010 11:19, Alvaro Herrera escribió:
> > Excerpts from Rensi Arteaga Copari's message of lun sep 27 10:35:22 -0400 2010:

> >> #deadlock_timeout = 1000 # in milliseconds
> >> *#max_locks_per_transaction = 64 # min 10*
> > Ok ... quizás podrías intentar aumentar ese valor un poco.
>
> Cual es el valor que tiene
>
> max_locks_per_transaction
>
> por defecto ? vien con el mínimo 10 ??

64

> >>> ¿Por qué subiste tanto temp_buffers y work_mem?
> >> Como el servidor es grande y exclusivo para postgres buscamos aprovechar
> >> el hardware,
> >> en algún manual de tunning de postgres leímos que podíamos ir subiendo
> >> estos valores
> > Dudo mucho que temp_buffers te esté ayudando mucho. Te recomendaría
> > bajarlo al valor por omisión, si bien no tiene relación directa con tu
> > problema; pero ¿sabes lo que hace? ¿Qué mediciones hiciste para
> > determinar que subirlo servía de algo?
> tengo entendido que es el máximo número de buffers temporales que
> una sesión puede usar, se usan para acceder a las tablas temporales y
> para optimizar consultas que eran lentas en varios lugares usamos tablas
> temporales

Ya, pero esa memoria podría usarse mejor por parte del sistema
operativo.

> Tengo una tabla particionada físicamente con herencia
> t_registro_evento es el padre
> y cada mes se crea una tabla con sufijo del mes
>
> asi: t_registro_evento_9_2010
> t_Registro_evencto_8_2010
>
>
> tengo a la fecha 5 tablas con un total de 785204 registros

¿Es la única tabla particionada? Es difícil ver por qué podría causarse
este problema con tan pocas particiones. ¿Puedes aislar qué consulta es
la que causa el problema?

Para 785000 registros, no parece valer la pena el particionamiento. Y
ciertamente no con una partición por mes. Seguramente habría sido mejor
idea hacer particionamiento por año solamente.

--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support