Feedback-ID: ia2694551:Fastmail
Date: Fri, 9 Aug 2024 18:08:02 -0400
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Jelte Fennema-Nio <postgres@jeltef.nl>
Cc: Michael Paquier <michael@paquier.xyz>,
	Nathan Bossart <nathandbossart@gmail.com>,
 PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: libpq: Fix lots of discrepancies in PQtrace
Message-ID: <202408092208.2mhpq5dsz7hy@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CAGECzQQwXdvy2gMNChJcq4nT3HU1KzMfnS3PD_Erk3viFUpoQQ@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/202408092208.2mhpq5dsz7hy%40alvherre.pgsql>
Precedence: bulk

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/