Re: Removing support for COPY FROM STDIN in protocol version 2

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Removing support for COPY FROM STDIN in protocol version 2
Date: 2021-03-03 23:32:58
Message-ID: 1318732.1614814378@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Heikki Linnakangas <hlinnaka(at)iki(dot)fi> writes:
> On 04/02/2021 08:54, Michael Paquier wrote:
>> On Wed, Feb 03, 2021 at 11:29:37AM -0500, Tom Lane wrote:
>>> Then let's kill it dead, server and libpq both.

> Ok, here we go.

> One interesting thing I noticed while doing this:

> Up until now, we always used the old protocol for errors that happened
> early in backend startup, before we processed the client's protocol
> version and set the FrontendProtocol variable. I'm sure that made sense
> when V3 was introduced, but it was a surprise to me, and I didn't find
> that documented anywhere. I changed it so that we use V3 errors, if
> FrontendProtocol is not yet set.

> However, I kept rudimentary support for sending errors in protocol
> version 2. This way, if a client tries to connect with an old client, we
> still send the "unsupported frontend protocol" error in the old format.
> Likewise, I kept the code in libpq to understand v2 ErrorResponse
> messages during authentication.

Yeah, we clearly need to send the "unsupported frontend protocol" error
in as old a protocol as we can. Another point here is that if the
postmaster fails to fork() a child process, it has a hack to spit out
an error message without using backend/libpq at all, and that sends
in 2.0 protocol. IIRC that's partly because it's simpler, as well
as backward-friendly. So we should keep these vestiges.

I rebased the 0001 patch (it'd bit-rotted slightly), read it over,
and did some light testing. I found a couple of other places where
we could drop code: any client-side code that has to act differently
for pre-7.4 servers can lose that option, because it'll never be
talking to one of those now.

Patched psql, trying to connect to a 7.3 server, reports this:

$ psql -h ...
psql: error: connection to server at "sss2" (192.168.1.3), port 5432 failed: FATAL: unsupported frontend protocol

$

Conversely, 7.3 psql trying to connect to a patched server reports:

$ psql -h ...
psql: FATAL: unsupported frontend protocol 2.0: server supports 3.0 to 3.0

$

I'm not sure where the extra newlines are coming from, and it seems
unlikely to be worth worrying over. This behavior is good enough for me.

I concur that 0001 attached is committable. I have not looked at
your 0002, though.

regards, tom lane

Attachment Content-Type Size
0001-remove-protocol-2.0-support.patch text/x-diff 144.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message 'Alvaro Herrera' 2021-03-03 23:42:41 Re: PATCH: Batch/pipelining support for libpq
Previous Message Soumyadeep Chakraborty 2021-03-03 22:56:25 Re: PITR promote bug: Checkpointer writes to older timeline