Me alegra que este andando todo mejor. muchas gracias por compartir la
información.
Recuerda que puedes mejorar un más las comunicaciones de los WAL cuando
usas compression en los canales.
Ahora un truco, la compression solo usa una CPU. para tener compression
con varios canales puedes hacer
Hola Horacio.,
Te comento que finalmente encontramos la solución , y se
debió al parámetro de Postgresql "logical_decoding_work_mem", si bien
suena lógico modificarlo, solo después de un arduo trabajo de empezar a
acotar llegamos que estaba muy bajo y lo aumentamos a 16GB y funciona
Hola Horacio , gracias por la respuesta y disposición de ayudar , estamos
revisando con personal de redes lo que mencionas.,
de igual forma forma me interesa chequear que mi configuración de
replicación lógica este correcta, vi en este hilo
PostgreSQL: Re: Retraso de replicación debido al retraso r
> On 19/04/2023, at 2:07 AM, Fernando Monjes wrote:
>
> Hola Horacio , gracias por la respuesta y disposición de ayudar , estamos
> revisando con personal de redes lo que mencionas.,
> de igual forma forma me interesa chequear que mi configuración de replicación
> lógica este correcta, vi en
En Amazon en tu security group activa el ICMP type 3 : type 4 asegúrate que el
pmtud funciona. Desde tu máquina onPrem hace un tracepath
Si te entiendo bien el problema lo tienes cuando hay muchos datos y algo pasa
que deja de funcionar. Si es lo que sospecho en AWS estas con MTU 9000 o en tu
Hola Amigos
Tengo un problema, estoy con una instancia amazon aws donde tengo postgres
v13.8 y onpremise un postgres 14.7, tengo configurado una réplica lógica
nativa de 4 tablas usando slot plugin pgoutput, usando publicador en aws y
subscriptor en onpremise postgres , la bd en aws tiene total d
