| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com> |
| Cc: | "alvherre(at)alvh(dot)no-ip(dot)org" <alvherre(at)alvh(dot)no-ip(dot)org>, "iwata(dot)aya(at)fujitsu(dot)com" <iwata(dot)aya(at)fujitsu(dot)com>, "k(dot)jamison(at)fujitsu(dot)com" <k(dot)jamison(at)fujitsu(dot)com>, "'Kyotaro Horiguchi'" <horikyota(dot)ntt(at)gmail(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: libpq debug log |
| Date: | 2021-03-05 05:55:02 |
| Message-ID: | 1443696.1614923702@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com> writes:
> Oops, the logging facility needs the destination (conn->pfdebug). So, it will be:
> void pqLogMessage(PGconn *conn, bool toServer);
Right, and it'd need the debug flags too, so +1 for just passing the
PGconn instead of handing those over piecemeal.
But I think passing the message start address explicitly might be
better than having it understand the buffering behavior in enough
detail to know where to find the message. Part of the point here
(IMO) is to decouple the tracing logic from the core libpq logic,
in hopes of not having common-mode bugs.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jaime Casanova | 2021-03-05 05:58:47 | Re: SQL-standard function body |
| Previous Message | tsunakawa.takay@fujitsu.com | 2021-03-05 05:33:31 | RE: libpq debug log |