Re: libpq debug log

From: Andres Freund <andres(at)anarazel(dot)de>
To: "Jamison, Kirk" <k(dot)jamison(at)jp(dot)fujitsu(dot)com>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, "Iwata, Aya" <iwata(dot)aya(at)jp(dot)fujitsu(dot)com>, 'Jacob Champion' <pchampion(at)pivotal(dot)io>, 'Jim Doty' <jdoty(at)pivotal(dot)io>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, "nagata(at)sraoss(dot)co(dot)jp" <nagata(at)sraoss(dot)co(dot)jp>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 'Haribabu Kommi' <kommi(dot)haribabu(at)gmail(dot)com>
Subject: Re: libpq debug log
Date: 2019-02-18 02:37:58
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


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.


Andres Freund

Attachment Content-Type Size
wireshark.png image/png 218.2 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2019-02-18 02:49:31 Re: 2019-03 CF Summary / Review - Tranche #2
Previous Message Donald Dong 2019-02-18 02:27:13 Re: Actual Cost