[ezekiel68]

> The cancel lands on a process that has never heard of the query, and nothing happens.

> Peering fixes this. The processes are aware of one another, so a cancel that lands on the wrong process is forwarded to the one that actually owns the session.

I understand "peering" as a concept here but have never tried this with PostgreSQL before. May I ask:

A) Does PostgreSQL have a mode/setting for peering that makes this easy? I'm imagining a mechanism that either goes round robin (re-sending the cancel to peers until it doesn't return an error of some kind) or some metadata in the cancel request that enables the wrong-destination process to somehow identify the proper process.

B) And by what mechanism? If all the PostgreSQL processes are listening to clients via so_reuseport, I guess there must be some other IPC method used for the peering chatter.

[inigyou]

AI clearly wrote TFA. The cancellation thing is apparently a PgBouncer feature - the peering is between bouncer processes, not server processes. It sounds like it should be easy enough to make the bouncer process ID part of the cancel key.

[__s]

you encode information in the token, this was a motivation for postgres to remove 32 byte cap on tokens: https://www.postgresql.org/message-id/508d0505-8b7a-4864-a68...

See from slide 26 https://www.pgevents.ca/events/pgconfdev2024/sessions/sessio... Jelte's a pgbouncer maintainer, video of a talk on this by him: https://www.youtube.com/watch?v=X-nCHcZ6vQU

[ezekiel68]

Thanks for this!