[Davanum Srinivas (dims)]

On a large host ateapi's read/write pool defaulted to one connection per CPU (pgxpool's max(4, NumCPU)), so a few replicas exhausted PostgreSQL's 100 default slots and requests failed with remaining connection slots are reserved.

The installer now sets ATE_API_POSTGRES_POOL_MAX_CONNS to 20 per replica, and to 64 on --cluster-size size10 with the bundled PostgreSQL, which used to pin that through its DSN and is provisioned for it. An external database keeps 20, and an adopted Cloud SQL install keeps its recorded limit. A supplied value wins over the size profile; 0 is refused at install time. ateapi's own flag keeps its unset default, so a direct run still follows the DSN or pgxpool.

Docs: docs/guides/postgres.md, docs/guides/operator-install.md, docs/guides/benchmarking.md and docs/dev/cloud-sql-scaling-guide.md.

• Tests pass: go test -race ./cmd/ate-setup/... (new TestLoadPostgresPoolMaxConns, including size10 with an external database, and an adopted install without a recorded limit in TestCreateAPIServerEnvVarsAdoptsPostgresIdentity) and the new TestReadWritePoolConfigMaxConns in atepg, which pins that a set limit replaces the DSN's pool_max_conns and an unset one keeps it; go vet, golangci-lint.
• Appropriate changes to documentation are included in the PR

[Jeremy Alvis (iplay88keys)]

I think the reason for this fix is good, but the new default causes two problems:

🤖 AI review finding

1. Size10 clusters get fewer connections. For size10 clusters, ate-setup puts pool_max_conns=64 in the read/write connection string (Size10PostgresPoolParams). atepg.Connect replaces the connection string value when PoolMaxConns > 0. With a default of 20, this is always true, so size10 clusters drop from 64 to 20 connections. A pool_max_conns value that a user sets in their own connection string is also replaced.
2. The value 0 does not work for installed clusters. The flag help says that 0 keeps the connection string or pgx default. But the installer sets the limit through ATE_API_POSTGRES_POOL_MAX_CONNS, and loadFlagsFromEnv rejects values of 0 or less. Only a user who runs ateapi directly with the flag can use 0.

Possible fixes:

• Use 20 only when the connection string does not set pool_max_conns.
• Or set the default in ate-setup. ate-setup already sets the size10 limit, so all pool sizes would then be in one place.

Separately, two docs still show the old default of max(4, NumCPU): hack/install-ate.sh and tools/setup-gcp/cloud-sql.md.

Please also add a test for the new default and for a connection string that already sets pool_max_conns. That test would find the size10 problem.

[Davanum Srinivas (dims)]

Jeremy Alvis (@iplay88keys) thank you for the review. i will explore the second option. will take care of the other things you pointed out as well

[Davanum Srinivas (dims)]

Jeremy Alvis (@iplay88keys) Done and ready. PTAL

[Jeremy Alvis (iplay88keys)]

I'm not sure my approval carries mergeability weight, so you'll want a review by one of the maintainers.

That being said, here's a follow-up review:

🤖 AI review finding
One new behavior change needs a decision:

The size10 limit now also applies to external PostgreSQL. Before this change, the limit of 64 was only in the bundled connection string. Now buildConfig sets 64 for every size10 install (load.go:182). A size10 cluster on Cloud SQL or another external database now opens up to 64 connections per replica. The external database might not accept that many. Is this the intended behavior? If not, use the size10 limit only with bundled PostgreSQL. If it is, please add it to tools/setup-gcp/cloud-sql.md and docs/dev/cloud-sql-scaling-guide.md.

Nits:

• atepg.go: readWritePoolConfig now sits between poolConfig and its doc comment. Move the poolConfig comment down to its function.
• load.go: the comment "see the roles" is not clear. Say what the flag is for, for example "lets an adopted install keep its recorded limit".
• docs/operator-install.md: the default column shows 20. Add that size10 uses 64.

[Davanum Srinivas (dims)]

I'm not sure my approval carries mergeability weight, so you'll want a review by one of the maintainers.

You are all i've got :)