O knob que parece um limite de conexões — e não é

The €100 Lakehouse — 4/12

Primeiro load completo, 42 tabelas, e o pool rebentou: «QueuePool limit of size 5 overflow 0 reached». As quatro tabelas-piloto tinham cabido em cinco conexões por acidente.

O mecanismo: o dlt abre um pipe por recurso, e cada generator suspenso segura uma conexão viva. O modo default, round_robin, circula por todos — logo ficam todos abertos ao mesmo tempo.

O fix óbvio é max_parallel_items. Lê-se como um limite de conexões. Medi em vez de confiar no nome:

→ fifo, max_parallel_items=4 → pico: 1 conexão. OK.
→ round_robin, max_parallel_items=1 → pico: 5. Falhou.

O knob limita items em voo, não pipes abertos. Aqui, não controla nada.

Reparem no lado que partiu. Com max_overflow=0, as conexões extra são recusadas — a promessa ao RDS de produção partilhado (que também serve a API da plataforma, o ETL legado e um Metabase vivo) aguentou, e foi o meu load que falhou. É o lado certo. A alternativa exportava o problema para a plataforma, onde o sintoma é um membro que não consegue marcar aula.

Os picos medidos vivem agora no ficheiro de settings e num teste, porque a "simplificação" plausível reproduz o outage exatamente. O load: 134.628 linhas em 37 tabelas, no primeiro run completo offline.

Um limite que faz o teu load falhar primeiro é um limite a funcionar.

Qual foi o knob com o melhor nome que já vos apareceu — e que afinal não controlava nada do que vos importava?

Databricks · dbt · Airflow · Terraform · AWS

P.S. Novo post tech todas as quartas-feiras.

#100EuroLakehouse #DataEngineering #PostgreSQL