From 436c0fee4d96d3bae5f408efd4b7352ec20161f1 Mon Sep 17 00:00:00 2001 From: Jinwoo-H Date: Fri, 4 Sep 2026 08:55:23 -0400 Subject: [PATCH] docs(cloud): dial-timeout burst shape and path attribution --- cloud/docs/relay-reconnect-2026-09-findings.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/cloud/docs/relay-reconnect-2026-09-findings.md b/cloud/docs/relay-reconnect-2026-09-findings.md index f42362617a8..4e1b4a4c409 100644 --- a/cloud/docs/relay-reconnect-2026-09-findings.md +++ b/cloud/docs/relay-reconnect-2026-09-findings.md @@ -541,7 +541,12 @@ proxies in bursts, which is exactly the "2 s connect timeout" the old image dies MATERIALIZED …`) and 469 s to the single-row reservation UPDATE: the lock queue is the *consequence* of connections stalling mid-transaction, not the cause. Not chased further; candidates are the proxy's connection churn under the crash loops (each recreated cell opens a fresh pool) and the instance's -public-IP path. Relay code cannot fix this; it is Cloud SQL / network. +public-IP path. Relay code cannot fix this; it is Cloud SQL / network. Dial timeouts by minute today: 12:20 24, 12:21 +66, 12:41 22, 12:42 6, 12:51 160, 12:52 137, i.e. bursts of 20–160 s each, and they hit c7 (new image, +89 today) and c8 (93) hardest, so it is not the old image's connection churn either. Cloud SQL `up`=1 +throughout. The proxy dials the instance's public IP `35.188.82.89:3307`; a burst of i/o timeouts to a +healthy instance points at the path (public-IP egress / NAT / proxy connection limits), not at Postgres. +That is the same 2 s that the old image dies on and that the new director surfaces as a 500. ## Roll inputs (verified by the read-only `verify` run)