6 ms·
> 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 canc
by ezekiel68 2mo ago
> 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 2mo agoAI 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 2mo agoyou 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-a681-e7e5edfe32aa@iki.fi https://www.postgresql.org/message-id/508d0505-8b7a-4864-a68... See from slide 26 https://www.pgevents.ca/events/pgconfdev2024/sessions/session/107/slides/48/2024-05-29-the-postgres-protocol%20(split).pdf 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 https://www.youtube.com/watch?v=X-nCHcZ6vQU
- ezekiel68 2mo agoThanks for this!