Pushed 0002 and 0003. On the latter: I decided against using int32 to print the request identifiers; by splitting into two int16's, we see that the numbers match the values in the PG_PROTOCOL() declarations:
2024-08-09 17:37:38.364622 F 8 SSLRequest 1234 5679 and 2024-08-09 17:37:38.422109 F 16 CancelRequest 1234 5678 NNNN NNNN (I didn't verify GSSEncRequest directly.) I also verified that in non-regress mode, the values printed by CancelRequest match those in the BackendKeyData message, 2024-08-09 17:34:27.544686 B 12 BackendKeyData NNNN NNNN I also added suppression in regress mode for the backend key in the CancelRequest message, since they would be different each time. There are no tests for this code. We could add a trace file for the connection packet in libpq_pipeline by changing PQconnectdb() to PQconnectStart() and then do PQtrace before polling until the connection is ready; we would have to have it match for the TAP test. Not sure this is worth the effort. But doing this in a very crude way allowed me to verify that, at least on my machine, this code is doing what's expected. Thank you, -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
