[piyush295]

Bug (fixes #2680)

Pool.Acquire pings connections that have been idle longer than ShouldPing says. The ping was wired to the caller's context, so cancellation mid-ping tripped pgconn's context watcher, broke the socket, failed the ping, and res.Destroy() took out a connection the pool had no reason to lose. The same thing happened when the caller's context was already cancelled before we got here: Ping returned immediately and the untouched connection was destroyed.

In code that fires parallel short queries and cancels the losers once one branch answers (an OpenFGA-style authorization server was the reported case) this produced a steady stream of reconnects that none of the destroy counters recorded (only NewConnsCount went up).

Fix (three guards)

1. If ctx is already cancelled before the ping, release the resource and return ctx.Err() instead of pinging. The ping would fail anyway and we would blame the connection.
2. Run the ping on context.WithoutCancel(ctx) (still bounded by pingTimeout when configured) so a cancel mid-ping cannot reach into pgconn and tear down the connection.
3. After a successful ping, re-check ctx.Err(). The caller may have cancelled while the ping was in flight; the connection is healthy so release it rather than destroy it, and surface the caller's error.

Behaviour for genuine ping failures (unreachable backend, auth error, etc.) is unchanged: the connection is still destroyed and the acquire loop retries. The caller still gets context.Canceled.

Test

TestPoolAcquirePingDoesNotDestroyOnCallerCancel runs with MaxConns=1 and ShouldPing: true, cancels the acquire context, and asserts that NewConnsCount is unchanged and the backend PID is the same on the next acquire. The test needs PGX_TEST_DATABASE just like the other pool tests.

go build ./... and go vet ./pgxpool/ are clean.

[jackc]

Closed in favor of #2681