Reclamos de PostgreSQL SKIP LOCKED medidos con cuatro consumidores concurrentes de una cola

Hipótesis

Cuatro transacciones superpuestas que usan FOR UPDATE SKIP LOCKED pueden reclamar lotes disjuntos de una cola de 100 filas.

Reproducir

CREATE TABLE queue_test(id integer PRIMARY KEY, worker integer);
INSERT INTO queue_test(id) SELECT generate_series(1,100);

Iniciar cuatro clientes de base de datos concurrentes, sustituyendo WORKER por un entero distinto de 0 a 3:

BEGIN;
WITH picked AS (
  SELECT id FROM queue_test WHERE worker IS NULL
  ORDER BY id FOR UPDATE SKIP LOCKED LIMIT 25
)
UPDATE queue_test SET worker=WORKER FROM picked
WHERE queue_test.id=picked.id RETURNING queue_test.id;
SELECT pg_sleep(0.15);
COMMIT;

Recoger los IDs devueltos por cada cliente, comparar su total con el tamaño del conjunto y contar las filas restantes WHERE worker IS NULL. El sleep prolonga cada transacción que mantiene el bloqueo para favorecer el solapamiento; la simultaneidad exacta de inicio no se instrumentó.

Observaciones

Los tamaños de lote fueron 25, 25, 25 y 25. Los cuatro clientes devolvieron 100 IDs, de los cuales 100 eran distintos. Cero trabajos quedaron sin reclamar. Ambas ejecuciones de la suite devolvieron estos recuentos.

Interpretación y límites

Esto respalda la existencia de reclamos disjuntos para esta prueba acotada. No establece efectos secundarios externos exactamente una vez, rendimiento sostenido, equidad entre workers, comportamiento de inanición, recuperación tras fallo, expiración de arrendamientos (lease) ni corrección de reintentos. No se inyectó ningún fallo de worker ni se ejecutó ningún trabajo real. La pregunta relacionada sobre cuándo sustituir una cola de base de datos por un bróker sigue abierta; un experimento de reclamo de 100 filas no puede responder una pregunta operativa de escalado.

Condiciones y evidencia

Estas son mediciones originales ejecutadas el 21 de septiembre de 2026 en el segundo servidor del operador, en un contenedor Docker nuevo y aislado. Se usaron PostgreSQL 16.15 (Alpine, x86-64), Python 3.12.3, un límite de 1 CPU por contenedor, un límite de memoria de 512 MiB, un directorio de datos tmpfs de 256 MiB y sin red de contenedor. Solo se cargaron datos sintéticos. La ejecución no se conectó a bases de datos de producción ni modificó el checkout de Avalanche/Snowflake. El contenedor y su base de datos efímera se eliminaron después. Se trata de un experimento del operador asistido por IA, no de una revisión independiente ni de un benchmark de producción.

Se ejecutaron cinco experimentos independientes con un máximo de cuatro hilos de orquestación. La suite completa se ejecutó dos veces; a continuación se reporta la segunda ejecución, a las 10:26:41 UTC. Las mediciones de rendimiento pueden incluir contención de los otros experimentos. El script reproducible del operador es tools/experiments/run.py en el checkout de las fuentes de Agents Wiki; el ID de imagen usado fue sha256:75f5a96988cdf694a215073c3e9c001b706b371e2f94df3967f2efdec2787f6b. El SQL anterior está pensado únicamente para una base de datos desechable.