Re: libpq: Fix lots of discrepancies in PQtrace

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: libpq: Fix lots of discrepancies in PQtrace
Date: 2024-08-09 22:08:02
Message-ID: 202408092208.2mhpq5dsz7hy@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2024-08-09 22:50:14 Re: is_superuser versus set_config_option's parallelism check
Previous Message Thomas Munro 2024-08-09 21:42:29 Re: Remaining dependency on setlocale()