Re: libpq: Bump protocol version to version 3.2 at least until the first/second beta

From: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
To: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
Cc: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: libpq: Bump protocol version to version 3.2 at least until the first/second beta
Date: 2026-02-18 20:27:56
Message-ID: CAOYmi+=Hi_on8cGe2TV7DRLbcvVQmrhdkyzOXbhT_6xqf02+4A@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Feb 9, 2026 at 3:56 PM Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> wrote:
> Looks like a good improvement. As said before I'm fine with either location for the URL.

Thanks, squashed in v8.

> I'm wondering if we should be a bit more liberal in showing this error explanation, since I expect most servers to throw an error rather than send an incorrect negotiation. e.g. We could report it on hard connection closures. Or if there is "3.9999" or "version" or "_pq_" in the error message. (the message should then be "this could indicate a bug in..." because we're not fully certain)

I think this is a great point, but I don't want to turn a clear signal
of "bug somewhere in the server, investigate now" into "maybe a bug,
probably just work around it". I don't really want anyone to be able
to (correctly) say that you can ignore this message in X case.

I took a look at some old implementation behaviors, and I think that
if a server responds to our startup packet with either a protocol
violation code or the literal grease version number (maybe in decimal,
maybe in other formats) in the error message, that's probably a clear
enough signal that something is wrong with the server. I've
implemented that idea in v8-0002. Maybe "_pq_." would be an okay
marker, too?

Would this patch result in desirable behavior for a legacy pgbouncer deployment?

--Jacob

Attachment Content-Type Size
v8-0001-libpq-Grease-the-protocol-by-default.patch application/octet-stream 11.8 KB
v8-0002-squash-libpq-Grease-the-protocol-by-default.patch application/octet-stream 2.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andreas Karlsson 2026-02-18 20:30:06 Re: Comment for UserMappingPasswordRequired in contrib/postgres_fdw
Previous Message Etsuro Fujita 2026-02-18 20:23:26 Comment for UserMappingPasswordRequired in contrib/postgres_fdw