Re: log de error de fdw

Jaja, Horacio no estoy del todo de acuerdo con las apreciaciones de DBA 2.0
pero gracias de todos modos.
Pude solucionar el problema modificando el seteo del server postgres_fdw y
desactivando ssl
ALTER SERVER backup OPTIONS (ADD sslmode 'disable');

El mar, 23 abr 2024 a las 19:17, Horacio Miranda (<hmiranda(at)gmail(dot)com>)
escribió:

> en general "*Connection reset by peer*”
> significa que el otro lado cerro el socket.
>
> En redes donde pasa esto, hay firewalls y estos dependiendo como estén
> configurados van a cerrar el socket usualmente en 120 segundos otros 240
> segundos y otros en 60 segundos. según las configuraciones por que las
> cierran.
>
> Se cierran los sockets que no tienen movimiento, por que ? ( por que los
> sockets son limitados y no puedes tener en un servidor sockets haciendo
> nada.
>
> Ahi es donde entra el keepalive, es información que se envia desde el
> cliente al servidor para decirle a los firewalls que no maten el socket que
> este canal es un pool y es de interes X mantenerlo abierto.
>
> Yo los uso a 30 segundos. ( tu mismo puedes hacer una prueba desde
> internet) a tu servidor desde el cliente de tu computador hace un psql y
> dejalo ahi sin hacer nada… toma un cafe, despues de 5 min revisa si esta
> aun viva la conección.
>
> [image: TCP-Keepalive-for-a-Better-PostgreSQL-Experience-comic-square.png]
>
> TCP keepalive for a better PostgreSQL experience
> <https://www.cybertec-postgresql.com/en/tcp-keepalive-for-a-better-postgresql-experience/>
> cybertec-postgresql.com
> <https://www.cybertec-postgresql.com/en/tcp-keepalive-for-a-better-postgresql-experience/>
>
> <https://www.cybertec-postgresql.com/en/tcp-keepalive-for-a-better-postgresql-experience/>
>
> Uso de parámetros en su instancia de base de datos de RDS for PostgreSQL -
> Amazon Relational Database Service
> <https://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Parameters.html>
> aws.amazon.com
> <https://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Parameters.html>
> [image: favicon.ico]
> <https://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Parameters.html>
> <https://docs.aws.amazon.com/es_es/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Parameters.html>
>
> Si quieres ser un DBA 2.0 debes saber todo lo que rodea a la base de
> datos, esto incluye hardware, redes y apps.
>
> Espero que esto te ayude un poco
> NOTA: Sí esto chino, solo habilita el keepAlive y veras magia pasar los
> mensajes esos deberian desaparecer por que ? los unicornios existen y es
> magia funcionando, el keepAlive abre una ventana magica al mundo de los
> logs malos y los hace desaparecer ( solo estoy poniendo un poco de humor si
> no entendiste nada de lo que hablan los links ).
>
> Que tengas un bonito día.
>
> On 24/04/2024, at 2:13 AM, Guillermo E. Villanueva <guillermovil(at)gmail(dot)com>
> wrote:
>
> Gracias Horacio por tu respuesta, mis conocimientos a nivel de sistema
> operativo y de redes no dan para esta revisión, pero por lo que estuve
> viendo en algunas listas (en ingles) tuvieron este problema ya con
> postgres_fdw (
> https://www.postgresql.org/message-id/4004.1521759312%40sss.pgh.pa.us) y
> hasta lo consideraron un bug, se enredó tanto la lista que me perdí perdón,
> ¿habrá alguien que ya tuvo este problema?
>
> El vie, 19 abr 2024 a las 11:17, Horacio Miranda (<hmiranda(at)gmail(dot)com>)
> escribió:
>
>> Ese mensaje te dice que la conección se esta muriendo, puede que te falte
>> un keepalive, que los firewall de haber dejen de inspeccionar el puerto. O
>> tengas un problema a nivel de MTU/MSS y/o tengas los icmp bloqueados ( las
>> fragmentaciones no se recalculan por que los routers no pueden informarte
>> que los paquetes son muy grandes y esta información viaja con el ICMP tipo
>> 8 y 11.
>>
>> Ignoro cual de todos o una combinación de ellos tienes, trata un tema a
>> la vez y revisa, ahora si haces una captura tcpdump te puedes hacer una
>> idea de cuanto ocurre.
>>
>> Debes adaptar este tcpdump a tu tarjeta.
>>
>> tcpdump -fnni bond0:-nnvvS -w dump.pcap 'tcp[tcpflags] & (tcp-rst) !=0’
>> [image: apple-touch-icon(at)2(dot)png]
>>
>> tcpdump capturing tcp resets by host
>> <https://serverfault.com/questions/517022/tcpdump-capturing-tcp-resets-by-host>
>> serverfault.com
>> <https://serverfault.com/questions/517022/tcpdump-capturing-tcp-resets-by-host>
>>
>> <https://serverfault.com/questions/517022/tcpdump-capturing-tcp-resets-by-host>
>>
>> En palabras simples, el mensja es Importante, no lo ignores. un error es
>> un error y deben ser arreglados.
>>
>> On 20/04/2024, at 12:38 AM, Guillermo E. Villanueva <
>> guillermovil(at)gmail(dot)com> wrote:
>>
>> Hola gente buen día, a pesar de que postgres_fdw está funcionando bien ,
>> el servidor destino de la conexión permanentemente está haciendo log
>> similar a:
>> usuario(at)serverorigen host="acá aparece la ip del origen de la conexion"
>> app=postgres_fdw LOG: no se pudo recibir datos del cliente: Connection
>> reset by peer
>> La conexión postgres_fdw funciona bien y obtengo los datos que necesito
>> con tablas foraneas.
>> origen postgres 13
>> destino postgres 12
>> ¿Puedo hacer que el postgres destino deje de loguear ese mensaje?
>> en postgresql.conf tengo:
>> client_min_messages = error
>> log_min_messages = error
>> log_min_error_statement = error
>>
>> Desde ya muchas gracias!!
>>
>>
>>
>