Radar
Lo que leo y por qué me importa
Programación con oficio: .NET, Python, bases de datos y cómo los agentes están cambiando el trabajo. Las notas las propone un agente mío; las que ves aquí las he leído y aprobado yo. Con mis palabras y con enlace al original.
26 de septiembre de 2026 · Planet PostgreSQL
Segunda entrega: fallos en extensiones de seguridad de Postgres gestionado
Mehmet Ince continúa su serie sobre riesgos en servicios de PostgreSQL gestionado. En esta segunda parte se centra en las extensiones de "security hardening" que los vendors usan para evitar ataques y malas configuraciones. Tras hablar con gestores de servicios, ingenieros de seguridad y red teamers, constata que ninguno monitorizaba la técnica de backdoor de superusuario vía shared buffers que describió en la primera parte. Databricks fue de los pocos vendors en responder públicamente. El tema completo no cabe en su charla de 40 minutos en PGCONF.EU, de ahí este post adicional.
Por qué me importa: Si administro o evalúo un Postgres gestionado, debería preguntar al proveedor si monitoriza este vector de ataque concreto sobre shared buffers y no dar por hecho que las extensiones de hardening cierran todos los agujeros. Merece la pena seguir la serie completa antes de confiar ciegamente en el marketing de seguridad de estos servicios.
Leer el original en Planet PostgreSQL →
26 de septiembre de 2026 · Planet PostgreSQL
pgBackRest: por qué no debes saltarte archive_mode tras un failover
Stefan Fercot analiza un caso real: alguien promovió un standby con archive_mode=off y quería evitar reiniciar el nuevo primario. Intentaron activar el archivado en un standby downstream y hacer el backup desde ahí, pero pgBackRest falló con "archive_mode must be enabled", incluso usando archive-mode-check=n. Tocando el código fuente de pgBackRest consiguieron que la prueba de concepto funcionara, pero eso no garantiza que la recuperación sea fiable. Monta un entorno de tres VMs con AlmaLinux 10 y PostgreSQL 18 en replicación en cascada para reproducirlo y explicar qué comprueba realmente la herramienta.
Por qué me importa: Si gestionas failovers con pgBackRest, esto te avisa de que saltarte comprobaciones de archive_mode con hacks puede darte un backup que restaura pero no recupera correctamente. La recomendación es clara: vuelve a una configuración soportada (restart o switchover controlado) antes de fiarte de atajos.
Leer el original en Planet PostgreSQL →
26 de septiembre de 2026 · Martin Fowler
El riesgo real de la IA no es una rebelión futura, es cómo la conectamos hoy
Rob Bowley, citado en el blog de Martin Fowler, discrepa del debate mediático sobre una IA futura que nos destruya. Su preocupación es otra: agentes de IA actuales conectados a todo, deprisa y sin cuidado, muchas veces con el patrón que llama "Lethal Trifecta", un agujero de seguridad conocido. Recuerda que los ciberataques ya generan pérdidas millonarias sin que intervenga ninguna IA. El mismo boletín recoge otra reflexión, de Nikita Prokopov, sobre el resaltado de sintaxis: colorear cada elemento del código lo satura todo y nada destaca de verdad.
Por qué me importa: Si despliegas agentes de IA con acceso a herramientas, datos y salida a internet a la vez, revisa esa combinación antes de preguntarte por escenarios de ciencia ficción: el problema de seguridad está en la arquitectura que montas hoy, no en el modelo del futuro.
Leer el original en Martin Fowler →
26 de septiembre de 2026 · Planet PostgreSQL
Diez años de replicación lógica en Postgres: de Londiste/PgQ a SQL puro
Dimitri Fontaine arranca una serie sobre replicación lógica en Postgres, que llegó con la versión 10 en 2017 y que ahora, con la 19, cumple diez entregas. Cuenta cómo montaba arquitecturas de hub y workers con Londiste y PgQ: triggers en cada tabla, colas por nodo, un ticker y un daemon Python por salto. Repasa qué de esa fontanería se ha ido sustituyendo por líneas de SQL en cada release, y anuncia posts sobre consolidación de esquemas con CDC y upgrades mayores sin caída de servicio.
Por qué me importa: Si todavía mantienes montajes de replicación con triggers y colas caseras, merece la pena revisar qué de eso ya resuelve el propio Postgres con logical replication nativa antes de seguir arrastrando esa complejidad.
Leer el original en Planet PostgreSQL →
26 de septiembre de 2026 · Planet PostgreSQL
Cuando el disco de Azure supera 4 TiB, Postgres se vuelve lento (y no es culpa suya)
Umair Shahid cuenta el caso de un cliente que pasó casi una semana tocando shared_buffers, effective_cache_size, work_mem y el resto de parámetros habituales sin arreglar unas lecturas lentas. El motivo real: su disco de datos en Azure llegó a 4 TiB y, al superarlo, Azure desactivó el host caching que hasta entonces servía buena parte de las lecturas desde memoria y SSD local sin ir al disco remoto. Postgres no tiene forma de detectar eso: solo espera, y esa espera se parece mucho a una base de datos mal ajustada.
Por qué me importa: Si administro Postgres en Azure con discos grandes, antes de tocar parámetros de memoria conviene mirar el tamaño del disco y si sigue activo el host caching. Un límite de infraestructura puede disfrazarse perfectamente de problema de tuning.
Leer el original en Planet PostgreSQL →
20 de septiembre de 2026 · .NET Blog
Serie en directo para construir un agente de IA en C# desde cero
Microsoft Reactor lanza una serie de 4 sesiones en directo donde se construye, paso a paso, un agente en C# usando Microsoft Agent Framework. Se parte de una llamada simple a IChatClient y se va llegando a un agente en producción, observable y gobernado. El proyecto se llama MafClaw y es código en vivo, no una charla teórica sobre el framework.
Por qué me importa: Si trabajas en .NET y quieres entender de verdad cómo montar un agente serio (no un demo de juguete), aquí tienes el proceso completo grabado en formato serie, que puedes seguir y replicar con tu propio código.
Leer el original en .NET Blog →