talmacschen-arch commented on issue #1830: URL: https://github.com/apache/cloudberry/issues/1830#issuecomment-4932401928
One correction to my earlier reply, where I offered `--connection-mode=pull` as a NAT/firewall workaround — that reasoning was wrong, and the real mechanism is worth recording here for anyone who hits this. The 600 s listener deadline (`helper/server.go`) only bites one specific configuration: **push mode when the destination cluster has fewer segments than the source** (the `ExtDestLtCopy` strategy). In that combination the destination segments listen with `--client-numbers > 1`, so the helper runs as a `ConcurrentServer` whose accept loop stays alive for the *entire* transfer — and the absolute 600 s listener deadline therefore caps the whole transfer, tearing it down mid-stream → 22P04. Your `client-numbers 4,4,4,4,3,3,3,3` (8 destination segments, 28 source segments) is exactly this dest-fewer-than-source push case. `--connection-mode=pull` fixes it not for any network reason, but because it swaps which side listens: in pull the **source** segments listen, and without `--client-numbers` the helper runs as a `OneTimeServer`, which closes its listener immediately after accepting its single connection. The data transfer then streams with no deadline at all, so it can run as long as it needs to. (The other strategy, `ExtDestGeCopy` for dest ≥ src, also listens without `--client-numbers` → `OneTimeServer`, so it isn't affected in either mode.) **Practical takeaway:** if your destination cluster has fewer segments than your source, use `--connection-mode=pull` for large tables — that's the clean workaround, no environment change needed. The proper fix belongs in the helper: the `ConcurrentServer` should bound only the initial connection-accept phase (or use an idle / no-progress timeout on the data connections), not cap total transfer time with a fixed listener deadline. I'll raise that on the cbcopy tracker. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
