RE: libpq debug log

From: "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com>
To: "k(dot)jamison(at)fujitsu(dot)com" <k(dot)jamison(at)fujitsu(dot)com>, "iwata(dot)aya(at)fujitsu(dot)com" <iwata(dot)aya(at)fujitsu(dot)com>
Cc: "'pgsql-hackers(at)lists(dot)postgresql(dot)org'" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: RE: libpq debug log
Date: 2020-12-22 00:53:15
Message-ID: TYAPR01MB299075EBBF27F9FCB6E7D1EAFEDF0@TYAPR01MB2990.jpnprd01.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

From: k(dot)jamison(at)fujitsu(dot)com <k(dot)jamison(at)fujitsu(dot)com>
> I understand that protocol 2.0 is still supported, but it is only used for
> PostgreSQL versions 7.3 and earlier, which is not updated by fixes anymore
> since we only backpatch up to previous 5 versions. However I am not sure if
> it's a good idea, but how about if we just support this feature for protocol 3.

+1
I thought psqlODBC (still) allows the user to choose the protocol version, it looks like the current psqlODBC disallows pre-3 protocol:

[libpq_connect()]
MYLOG(0, "libpq connection to the database established.\n");
pversion = PQprotocolVersion(pqconn);
if (pversion < 3)
{
MYLOG(0, "Protocol version %d is not supported\n", pversion);
goto cleanup;
}

> There are similar chunks of code in fe-exec.c, PQsendPrepare(),
> PQsendDescribe(),
> etc. that already do something similar, so I just thought in hindsight if we can
> do the same.
> if (PG_PROTOCOL_MAJOR(conn->pversion) >= 3)
> {
> <new code here>
> }
> else
> {
> /* Protocol 2.0 isn't supported */
> printfPQExpBuffer(&conn->errorMessage,
> libpq_gettext("function requires at least protocol
> version 3.0\n"));
> return 0;
> }

I haven't looked at the patch and don't know the code structure, but I want the code clutter to be minimized. So, I think we should avoid putting if statements like above here and there.

Plus, I don't think it's not necessary to fail the processing when the protocol version is 2; we can just stop the trace output. So, how about disabling the trace output silently if the protocol turns out to be < 3 upon connection?

Regards
Takayuki Tsunakawa

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2020-12-22 01:07:09 Re: Fix generate_useful_gather_paths for parallel unsafe pathkeys
Previous Message Andres Freund 2020-12-22 00:39:35 Re: Add statistics to pg_stat_wal view for wal related parameter tuning