Re: Dificil situacion con Lokcs...

Carlos T. Groero Carmona escribió:
> Daymel, gracias por su comentario.
>
> He estado manejando hipotesis donde el update se bloquea porque se queda
> esperando una validacion (otro query o trigger), se demora mas de 5
> segundos, el lock_timeout le dice a postgres que elimine esa transaction,
> la transaction se queda abierta, el script intenta ejecutar nuevos updates
> sobre las mismas filas,

No, esta hipótesis no es correcta, porque cuando una transacción es
abortada debido al lock_timeout, todos los locks que tiene son liberados
y ningún intento futuro para ejecutar cualquier cosa que no sea un
ROLLBACK tendrá ningún efecto. Únicamente te verías en un problema si
pusieras esto en un loop en plpgsql con un bloque EXCEPTION, o alguna
otra cosa similarmente absurda.

(Las transacciones no se "eliminan". Más bien se "abortan", quedando en
un estado en el cual no pueden continuar operando.)

> y como explico Daymel, esos procesos pasan a ser locks por transaiones

Esta última frase no tiene sentido.

> y como en mi configuracion tengo solo 128

Esta tampoco.

> postgres cae por el alto consumo de recursos de estas y otras
> operaciones.

Esta tampoco.

Creo que has diagnosticado mal el problema, aunque no me atrevo a
sugerir cuál podría ser un diagnóstico correcto.

> 1- Aumentar el shared_buffer a 64 GB como teniamos planificado y asi
> postgres tiene mas recursos para trabajar

Dudo que ayude.

> 2- Aumentar 10 veces como me recomendo alvaro el numero de locks por
> transaciones

Mismo.

> 3- Desabilitar el lock_timeout.

Esto podría cambiar el comportamiento, pero no creo que solucione en
problema de fondo.

> 4- disminuir el tiempo de log_duration o ponerlo en cero hasta que sel
> bloqueo suceda nuevamente y me permita tracear todas las transaciones
> realizadas en un tiempo sercano al primer lock en la tabla.

No entiendo esta idea.

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services