Correctly identify PgDog poolers

[paul-enz]

The problem

Hi @alexshapalov thanks for this useful tool! I'm interested in using PgBot and I have a couple of ideas for contributions. I'll create them as issues to see if you're interested in accepting changes to support them 😄 Let me know what you think.

Problem

PgBot currently treats hostnames containing -pooler as Neon pooled
endpoints. This incorrectly labels other (e.g. PgDog) installations that use custom domains.

Hostname and port conventions are deployment-specific and should not determine
whether a connection uses PgDog.

Proposed change

Add behavior-based PgDog detection using a PgDog-specific startup option that
PgDog consumes instead of forwarding to PostgreSQL.

Restrict Neon detection to native Neon pooled endpoint domains. Preserve
existing generic pooler detection for PgBouncer, Supabase, and unknown
transaction poolers.

Acceptance criteria

• PgDog connections are reported as PgDog.
• Detection works with custom PgDog hostnames and ports.
• No hostname specific to one deployment is used as a PgDog detection hint.

[alexshapalov]

Thanks for the well-framed issue @paul-enz you were right that hostname conventions have no business identifying a specific pooler. This is now implemented on main (80b518e) and will go out in the next release.

[alexshapalov]

Two things I learned testing this against a live PgDog (v0.1.54) that are worth writing down:

• Only session-level SET pgdog.shard is intercepted — SET LOCAL inside an explicit transaction is forwarded verbatim to the backend, even though the docs recommend the SET LOCAL form for routing. So the probe uses session-level SET with SET … TO DEFAULT cleanup.
• SET pgdog.sharding_key errors on a default (unsharded) config and poisons the session for every subsequent statement — the probe never touches it.

Against your acceptance criteria: PgDog connections now report as "connected via a PgDog pooler"; detection worked in my tests on an arbitrary host:port with no hostname involvement; and the Neon label now requires Neon's own domain — other -pooler hosts still count as a generic pooler signal but are labeled generically. There's an opt-in integration test (PGBOT_PGDOG_TEST_DSN) that runs the positive path through a real PgDog.

If you can point a build at your own PgDog deployment and confirm the label shows up, I'd take that as the final sign-off before closing. And yes — very much interested in your other contribution ideas, fire away.

[paul-enz]

Hi @alexshapalov my apologies for the delay. I pointed a latest build from source of PgBot at my PgDog deployment and can confirm the detection is working and I get the following notice:

pgbot: connected via a PgDog pooler — proceeding; rates are still correct (each counter is read in its own transaction). Pass --strict-pooler to refuse instead.

[paul-enz]

This is connecting to a PgDog deployment with a custom domain URL too, so this is great.