Horton

Re: libpq debug log

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: "Jamison, Kirk" <k.jamison@jp.fujitsu.com>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, "Iwata, Aya" <iwata.aya@jp.fujitsu.com>, 'Jacob Champion' <pchampion@pivotal.io>, 'Jim Doty' <jdoty@pivotal.io>, PostgreSQL mailing lists <pgsql-hackers@postgresql.org>, "nagata@sraoss.co.jp" <nagata@sraoss.co.jp>, Tom Lane <tgl@sss.pgh.pa.us>, 'Haribabu Kommi' <kommi.haribabu@gmail.com>
Date: 2019-02-18T02:37:58Z
Lists: pgsql-hackers

Attachments

Hi,

On 2019-02-18 02:23:12 +0000, Jamison, Kirk wrote:
> For Andres, I haven't looked into tcpdump yet, but I'd like to ask whether
> or not the decrypted output to .pcap (if implemented) may be useful to
> application users. What could be the limitations?
> Could you explain a bit further on the idea?

Well, wireshark (and also tcpdump in a less comfortable manner) has a
dissector for the postgresql protocol. That allows to dig into various
parts. See e.g. the attached as an example of what you can see as the
response to a SELECT 1;

Right now that's not usable if the connection is via TLS, as pretty much
all encrypted connection use some form of forward secrecy, so even if
you had access the the private key, we'd not be able to parse it into an
unencrypted manner.

Greetings,

Andres Freund

Commits

  1. Rename PQtraceSetFlags() to PQsetTraceFlags().

  2. Suppress length of Notice/Error msgs in PQtrace regress mode

  3. Strip file names reported in error messages on Windows, too.

  4. Fix setvbuf()-induced crash in libpq_pipeline

  5. libpq_pipeline: Must strdup(optarg) to avoid crash

  6. Remove setvbuf() call from PQtrace()

  7. Initialize conn->Pfdebug to NULL when creating a connection

  8. Disable force_parallel_mode in libpq_pipeline

  9. libpq_pipeline: add PQtrace() support and tests

  10. Improve PQtrace() output format

  11. Re-simplify management of inStart in pqParseInput3's subroutines.