What

Two small allocation reductions in the pool's hot acquire/release path, with no behavior or API change:

1. Register the per-query error listener with client.on('error', onError) instead of client.once(...). The query result callback already removes the listener on completion, and onError self-guards via the clientReleased flag, so once's per-query wrapper allocation was unnecessary.
2. Bind _pulseQueue once in the constructor (this._pulseQueueBound) and reuse that reference for the connect-path process.nextTick and the three _remove callbacks, instead of allocating a fresh bound function on every acquire/release.

Why

pool.query() is on the hot path for most applications. These changes remove one closure allocation per query (the once wrapper) and one bound-function allocation per acquire/release, lowering per-query GC pressure with no change to behavior.

Correctness

The once to on switch cannot double-fire or leak a listener:

• On success, the query callback calls client.removeListener('error', onError) before resolving.
• onError flips clientReleased to true on its first call and returns early on any later call, so it can release and call back at most once.
• On the error path the client is released with the error and removed from the pool, so no listener accumulates on a reused client.

No public API or observable behavior changes. waitingCount and all emitted events are unchanged.

Benchmark

Measured with a mock-client microbenchmark (no network, so it isolates the pool's own per-query overhead), alternating between this branch and base each round to cancel thermal drift. At concurrency 50 this change is about +2 to +3% queries/sec, with all three alternating rounds favoring it.

This is the allocation portion only. A separate change (O(1) pending-queue dequeue) adds more at high concurrency.

Testing

The full pg-pool suite passes (85 passing). The one failure in my environment is the unrelated pg-native bindings test, which requires a local libpq build.