fix(pg-pool): maintain min connections after maxUses/error retirement

[slukes]

Problem

The `min` pool option does not maintain a minimum number of live connections. It only prevents the idle timeout from evicting connections when at or below `min`. When connections are retired for other reasons — `maxUses`, `maxLifetimeSeconds`, or background errors — the pool shrinks below `min` and never refills unless a new query arrives.

Concretely, with `min: 15, max: 15, maxUses: `, a low-traffic window causes the pool to drain nearly to zero as each connection exhausts its use count and is removed without replacement.

There are two root causes:

1. `_pulseQueue` only refills for queued requests

`_pulseQueue` (called after every retirement via `_remove`'s callback) only creates new connections when `_pendingQueue` is non-empty. An idle pool with no waiting callers therefore never gets a refill.

2. `makeIdleListener` does not call `_pulseQueue`

When an idle client emits a background error, `makeIdleListener` called:

```js
pool._remove(client) // no callback — _pulseQueue is never called
```

This meant:

• The pool dropped below `min` with no refill
• Any `connect()` calls waiting in `_pendingQueue` were stuck indefinitely

Fix

`_ensureMinimum()` — a new method that synchronously schedules `newClient` calls for however many connections are needed to reach `options.min`:

```js
_ensureMinimum() {
if (this.ending || this.ended) return
const needed = this.options.min - this._clients.length
for (let i = 0; i < needed; i++) {
this.newClient(new PendingItem((err, client, clientRelease) => {
if (!err) clientRelease()
}))
}
}
```

Because `newClient` pushes to `_clients` immediately (before `connect()` resolves), the loop naturally caps at exactly `min` even when called multiple times concurrently.

Called from `_remove` immediately after the retiring client is spliced from `_clients`, covering every removal path: `maxUses`, `maxLifetimeSeconds`, and errors.

`makeIdleListener` now passes `_pulseQueue` as the `_remove` callback, so queued `connect()` callers are unblocked after an idle client errors out.

Tests

`test/min-connections.js` — new file using a mock `Client` (no real PG needed) with four scenarios:

Test	What it verifies
maxUses retirement → refill	Pool reaches `totalCount == min` after clients exhaust `maxUses`
Concurrent retirements → does not exceed min	`_ensureMinimum` does not overshoot `min` when multiple clients retire simultaneously
Idle-error → refill	Pool creates a replacement after a background error on an idle client
Idle-error → serves pending request	A queued `connect()` is resolved after the only idle client errors out

`test/sizing.js` — the existing `maxLifetimeSeconds` test that asserted `idleCount === 0` after expiry is updated: the correct new behaviour is that the pool refills to `min`, so the test now asserts `totalCount === 1` and `idleCount === 1` after the replacement connects.

Behaviour notes

• `pool.end()` is unaffected: `_ensureMinimum` returns immediately when `this.ending` is set, so teardown is clean.
• `maxUses: 1` with `min > 0` causes a continuous rolling churn of connections (each maintenance connection is used once and immediately replaced). This is technically correct — callers who want warm idle connections with `maxUses: 1` pay that cost — but it is worth noting in docs.

[charmander]

The `min` pool option does not maintain a minimum number of live connections. It only prevents the idle timeout from evicting connections when at or below `min`. When connections are retired for other reasons — `maxUses`, `maxLifetimeSeconds`, or background errors — the pool shrinks below `min` and never refills unless a new query arrives.

That’s what it’s documented to do (https://node-postgres.com/apis/pool):

Minimum number of clients the pool should hold on to and not destroy with the idleTimeoutMillis.
This can be useful if you get very bursty traffic and want to keep a few clients around.
Note: currently the pool will not automatically create and connect new clients up to the min, it will only not evict and close clients except those which exceed the min count.
The default is 0 which disables this behavior.

[slukes]

That’s what it’s documented to do (https://node-postgres.com/apis/pool):

Yes, my apologies. Would you be open to a PR that changes that behaviour in an opt in way when combined with maxUses?

To explain why I would want to do this:

• Service runs normally with around 15 connections to the DB
• Upstream service outage causes a large gap in traffic
• Health check pushes connections slowly over max uses
• End up with only 2 connections left to DB
• Traffic comes back and causes huge reconnection storm that can provoke a huge spike of timeouts