|From:||"Iwata, Aya" <iwata(dot)aya(at)jp(dot)fujitsu(dot)com>|
|To:||'Peter Eisentraut' <peter(dot)eisentraut(at)2ndquadrant(dot)com>|
|Cc:||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>, 'Jacob Champion' <pchampion(at)pivotal(dot)io>, 'Jim Doty' <jdoty(at)pivotal(dot)io>|
|Subject:||RE: libpq debug log|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Thank you for your reply!
> On 27/11/2018 08:42, Iwata, Aya wrote:
> > I created a new version patch. Please find attached my patch.
> This does not excite me. It seems mostly redundant with using tcpdump.
I will develop "log level". I'm planning not to output redundant message at the default level.
> If I were to debug networking problems, I wouldn't even trust this very much
> because it relies on the willpower of all future PostgreSQL developers to
> keep this accurately up to date, whereas tcpdump gives me the truth from the
I agree your concern about log trusty. It would be a good choice for only
skilled users to use tcpdump. I think libpq trace log will be used many users,
it includes users who not familiar with PostgreSQL protocols. The log would be easier to use
because it shows "start time" and "end time". On tcpdump also shows
the starting time and ending time but people need to know PostgreSQL protocol
to get them.
And this log also is useful for Windows users.
Windows does not have originally networking trace tool.
If you have any ideas about maintain this feature, I would like to know it.
|Next Message||John Naylor||2018-11-29 09:37:30||Re: WIP: Avoid creation of the free space map for small tables|
|Previous Message||legrand legrand||2018-11-29 09:23:28||Re: [PROPOSAL] extend the object names to the qualified names in pg_stat_statements|