refactor: use BackendPid instead of BackendKeyData where secret is not required#1025
Conversation
meskill
force-pushed
the
refactor/backend_key_data
branch
from
a12f655 to
6e8a433
Compare
| copy_out: usize, | ||
| copy_data: usize, | ||
| first_backend_data: Option<BackendKeyData>, | ||
| first_backend_data: Option<BackendPid>, |
There was a problem hiding this comment.
This is extremely unlikely, but the backend PIDs could collide (same PID, different servers). The secret kinda makes sure that cannot practically happen.
There was a problem hiding this comment.
It's not likely, but possible. One simple fix (to quote our favorite bot coworker) could be to generate a unique ID for each server connection (struct Server) and use that for identification instead of whatever info Postgres returns. I used BackendKeyData because it was convenient originally and seemed pretty futureproof, but protocol 3.2 made things a bit harder for sure here.
There was a problem hiding this comment.
refactored to the approach pid + seq counter for the backend pid to still have reference for the backend pid (if needed) and prevent collisions. Anyway, now it's a separate type and that should be easier to change if needed. Also, separated the pid types used for frontend/backend to make it more explicit and harder to mess up in the code
meskill
force-pushed
the
refactor/backend_key_data
branch
from
6e8a433 to
c7711f7
Compare
This comment has been minimized.
This comment has been minimized.
Codecov Report❌ Patch coverage is 📢 Thoughts on this report? Let us know! |
| @@ -63,11 +63,6 @@ impl AdminServer { | |||
| self.messages.extend(messages); | |||
| self.messages.push_back(ReadyForQuery::idle().message()?); | |||
|
|
|||
There was a problem hiding this comment.
I think we still want to apply the backend provencance so Debug works correctly. There are ambiguous message codes like D which could be either frontend or backend message (Describe or DataRow)
There was a problem hiding this comment.
yup, that's why I've added new Source::Internal variant to explicitly handle the case we were generate the message to the client, but we don't have the actual backend that resolved this, and the Internal is the default now.
levkk
left a comment
levkk
left a comment
There was a problem hiding this comment.
I think this is good. Double check the memory alloc inside put and take and also make sure the Debug output of admin messages didn't break.
2 participants
Refactor the codebase by using BackendKeyData (contains a connection secret) only where the secret is required, while all other places will use BackendPid (wrapper around u32) to refer the connection or store it. The BackendKeyData becomes complex type without copy and hash and it should be cloned where needed instead and it makes visible the non-free operation of 256 bytes array copying.
The performance benefits are not huge and I had to tweak the pgbench configuration with options
-t 10000 -c 100to see the difference around the commit #2f70a7a70cc8eceefe577f994e89b5e943e0724d that added the support for the extended secret.Benchmark comparisions
The performance difference is there. Integration test for cancellation has been added and some around refactoring have done.