Re: [HACKERS] Is it time to kill support for very old servers?

[Michael Paquier]

On Mon, Oct 16, 2017 at 10:08 PM, Andres Freund  wrote:
> On 2017-10-16 16:59:59 -0400, Peter Eisentraut wrote:
>> On 9/20/17 04:32, Andres Freund wrote:
>> > Here's what I roughly was thinking of.  I don't quite like the name, and
>> > the way the version is specified for libpq (basically just the "raw"
>> > integer).
>>
>> "forced_protocol_version" reads wrong to me.  I think
>> "force_protocol_version" might be better.  Other than that, no issues
>> with this concept.
>
> Yea, I agree. I've read through the patch since, and it struck me as
> odd. Not sure how I came up with it...

Andres, could you update the patch?
-- 
Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Is it time to kill support for very old servers?

[Andres Freund]

On 2017-10-16 16:59:59 -0400, Peter Eisentraut wrote:
> On 9/20/17 04:32, Andres Freund wrote:
> > Here's what I roughly was thinking of.  I don't quite like the name, and
> > the way the version is specified for libpq (basically just the "raw"
> > integer).
> 
> "forced_protocol_version" reads wrong to me.  I think
> "force_protocol_version" might be better.  Other than that, no issues
> with this concept.

Yea, I agree. I've read through the patch since, and it struck me as
odd. Not sure how I came up with it...

Greetings,

Andres Freund


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Is it time to kill support for very old servers?

[Peter Eisentraut]

On 9/20/17 04:32, Andres Freund wrote:
> Here's what I roughly was thinking of.  I don't quite like the name, and
> the way the version is specified for libpq (basically just the "raw"
> integer).

"forced_protocol_version" reads wrong to me.  I think
"force_protocol_version" might be better.  Other than that, no issues
with this concept.

-- 
Peter Eisentraut  http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Is it time to kill support for very old servers?

[Michael Paquier]

On Wed, Oct 11, 2017 at 10:28 PM, Robert Haas  wrote:
> On Tue, Oct 10, 2017 at 9:14 PM, Andres Freund  wrote:
>> I'm actually inclined not to, and keep this as a undocumented debugging
>> option. Limiting the use of this option to people willing to read the
>> code seems like a good idea to me.
>
> -1.  I use the documentation to find things, even though I am a
> developer, and I don't think hiding things from users is a good idea
> anyway.  We can say that we recommend against using the option and
> that it's just for testing, but it should be documented anyway.

You would be disappointed with the current state of things then.
fe-connect.c lists a couple of debug options:
- authtype, which is not used anywhere, still kept to not reject
connection strings using it. I can get that this is not documented.
- tty, same argument as authtype.
- replication, which is still available, and that I have for example
used a couple of times for debugging the replication parser (psql can
work directly with some replication commands as you know). But this is
not documented.

FWIW, I would like to see things properly documented as well. And
please note that I am fine to write such a patch as well.
-- 
Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Is it time to kill support for very old servers?

[Robert Haas]

On Tue, Oct 10, 2017 at 9:14 PM, Andres Freund  wrote:
> I'm actually inclined not to, and keep this as a undocumented debugging
> option. Limiting the use of this option to people willing to read the
> code seems like a good idea to me.

-1.  I use the documentation to find things, even though I am a
developer, and I don't think hiding things from users is a good idea
anyway.  We can say that we recommend against using the option and
that it's just for testing, but it should be documented anyway.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Is it time to kill support for very old servers?

[Michael Paquier]

On Wed, Oct 11, 2017 at 10:46 AM, Andres Freund  wrote:
> I'm not following. The "D" is in the 'dispchar' field, not the value
> field, no? The default value is NULL?

Oops, yes. I misread the code. Other debug options are not documented,
so fine for me to not provide any documentation then.
-- 
Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Is it time to kill support for very old servers?

[Andres Freund]

Hi,

On 2017-10-11 10:40:11 +0900, Michael Paquier wrote:
> >> +   if (conn->forced_protocol_version != NULL)
> >> +   {
> >> +   conn->pversion = atoi(conn->forced_protocol_version);
> >> +   }
> >> This should check for strlen > 0 as well.
> >
> > Why? Note that we don't do elsehwere in fe-connect.c.
> 
> Because it seems to me that the default value of the parameter should
> be an empty string instead of D. Feels more consistent with the
> others.

I'm not following. The "D" is in the 'dispchar' field, not the value
field, no? The default value is NULL?

Greetings,

Andres Freund


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Is it time to kill support for very old servers?

[Michael Paquier]

On Wed, Oct 11, 2017 at 10:14 AM, Andres Freund  wrote:
> Hi,
>
> On 2017-10-11 10:09:34 +0900, Michael Paquier wrote:
>> On Wed, Oct 11, 2017 at 9:39 AM, Andres Freund  wrote:
>> > On 2017-09-20 01:32:36 -0700, Andres Freund wrote:
>> >> Coverage of the relevant files is a good bit higher afterwards. Although
>> >> our libpq coverage is generally pretty damn awful.
>> >
>> > Any opinions on this? Obviously this needs some cleanup, but I'd like to
>> > know whether we've concensus on adding a connection option for this goal
>> > before investing more time into this.
>> >
>> > A nearby thread [1] whacks around some the v2 code, which triggered me
>> > to look into this. I obviously can just use thiese patches to test those
>> > patches during development, but it seems better to keep coverage.
>>
>> FWIW, I think that moving forward with such a possibility is a good
>> thing, including having a connection parameter. This would pay in the
>> long term if a new protocol version is added.
>
>> 0001 should document the new parameter.
>
> I'm actually inclined not to, and keep this as a undocumented debugging
> option. Limiting the use of this option to people willing to read the
> code seems like a good idea to me.

It seems important to me to document things present. There is a
section in the docs listing developer-only parameters for runtime
configuration, why not separating "Parameter Key Words" into two
sections then? One for the main parameters and one for developer-only
parameters.

>> +   if (conn->forced_protocol_version != NULL)
>> +   {
>> +   conn->pversion = atoi(conn->forced_protocol_version);
>> +   }
>> This should check for strlen > 0 as well.
>
> Why? Note that we don't do elsehwere in fe-connect.c.

Because it seems to me that the default value of the parameter should
be an empty string instead of D. Feels more consistent with the
others.
-- 
Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Is it time to kill support for very old servers?

[Andres Freund]

Hi,

On 2017-10-11 10:09:34 +0900, Michael Paquier wrote:
> On Wed, Oct 11, 2017 at 9:39 AM, Andres Freund  wrote:
> > On 2017-09-20 01:32:36 -0700, Andres Freund wrote:
> >> Coverage of the relevant files is a good bit higher afterwards. Although
> >> our libpq coverage is generally pretty damn awful.
> >
> > Any opinions on this? Obviously this needs some cleanup, but I'd like to
> > know whether we've concensus on adding a connection option for this goal
> > before investing more time into this.
> >
> > A nearby thread [1] whacks around some the v2 code, which triggered me
> > to look into this. I obviously can just use thiese patches to test those
> > patches during development, but it seems better to keep coverage.
> 
> FWIW, I think that moving forward with such a possibility is a good
> thing, including having a connection parameter. This would pay in the
> long term if a new protocol version is added.

> 0001 should document the new parameter.

I'm actually inclined not to, and keep this as a undocumented debugging
option. Limiting the use of this option to people willing to read the
code seems like a good idea to me.

> 
> +   if (conn->forced_protocol_version != NULL)
> +   {
> +   conn->pversion = atoi(conn->forced_protocol_version);
> +   }
> This should check for strlen > 0 as well.

Why? Note that we don't do elsehwere in fe-connect.c.


Greetings,

Andres Freund


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Is it time to kill support for very old servers?

[Michael Paquier]

On Wed, Oct 11, 2017 at 9:39 AM, Andres Freund  wrote:
> On 2017-09-20 01:32:36 -0700, Andres Freund wrote:
>> Coverage of the relevant files is a good bit higher afterwards. Although
>> our libpq coverage is generally pretty damn awful.
>
> Any opinions on this? Obviously this needs some cleanup, but I'd like to
> know whether we've concensus on adding a connection option for this goal
> before investing more time into this.
>
> A nearby thread [1] whacks around some the v2 code, which triggered me
> to look into this. I obviously can just use thiese patches to test those
> patches during development, but it seems better to keep coverage.

FWIW, I think that moving forward with such a possibility is a good
thing, including having a connection parameter. This would pay in the
long term if a new protocol version is added. 0001 should document the
new parameter.

+   if (conn->forced_protocol_version != NULL)
+   {
+   conn->pversion = atoi(conn->forced_protocol_version);
+   }
This should check for strlen > 0 as well.
-- 
Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Is it time to kill support for very old servers?

[Andres Freund]

On 2017-09-20 01:32:36 -0700, Andres Freund wrote:
> On 2017-09-18 02:53:03 -0700, Andres Freund wrote:
> > On 2017-09-13 23:39:21 -0400, Tom Lane wrote:
> > > The real problem in this area, to my mind, is that we're not testing that
> > > code --- either end of it --- in any systematic way.  If it's broken it
> > > could take us quite a while to notice.
> >
> > Independent of the thrust of my question - why aren't we adding a
> > 'force-v2' option to libpq?  A test that basically does something like
> > postgres[22923][1]=# \setenv PGFORCEV2 1
> > postgres[22923][1]=# \c
> > You are now connected to database "postgres" as user "andres".
> > postgres[22924][1]=>
> > seems easy enough to add, in fact I tested the above.
> >
> > And the protocol coverage of the v2 protocol seems small enough that a
> > single not too large file ought to cover most if it quite easily.
> 
> Here's what I roughly was thinking of.  I don't quite like the name, and
> the way the version is specified for libpq (basically just the "raw"
> integer).   Not sure if others have an opinion on that.  I personally
> would lean towards not documenting this option...
> 
> There's a few things that I couldn't find easy ways to test:
> - the v2 specific binary protocol - I don't quite see how we could test
>   that without writing C
> - version error checks - pg_regress/psql errors out in non-interactive
>   mode if a connection fails to be established. This we could verify
>   with a s simple tap test.
> 
> Coverage of the relevant files is a good bit higher afterwards. Although
> our libpq coverage is generally pretty damn awful.

Any opinions on this? Obviously this needs some cleanup, but I'd like to
know whether we've concensus on adding a connection option for this goal
before investing more time into this.

A nearby thread [1] whacks around some the v2 code, which triggered me
to look into this. I obviously can just use thiese patches to test those
patches during development, but it seems better to keep coverage.

Thanks,

Andres

[1] https://postgr.es/m/20170914063418.sckdzgjfrsbek...@alap3.anarazel.de


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Is it time to kill support for very old servers?

[Andres Freund]

On 2017-09-18 02:53:03 -0700, Andres Freund wrote:
> On 2017-09-13 23:39:21 -0400, Tom Lane wrote:
> > The real problem in this area, to my mind, is that we're not testing that
> > code --- either end of it --- in any systematic way.  If it's broken it
> > could take us quite a while to notice.
>
> Independent of the thrust of my question - why aren't we adding a
> 'force-v2' option to libpq?  A test that basically does something like
> postgres[22923][1]=# \setenv PGFORCEV2 1
> postgres[22923][1]=# \c
> You are now connected to database "postgres" as user "andres".
> postgres[22924][1]=>
> seems easy enough to add, in fact I tested the above.
>
> And the protocol coverage of the v2 protocol seems small enough that a
> single not too large file ought to cover most if it quite easily.

Here's what I roughly was thinking of.  I don't quite like the name, and
the way the version is specified for libpq (basically just the "raw"
integer).   Not sure if others have an opinion on that.  I personally
would lean towards not documenting this option...

There's a few things that I couldn't find easy ways to test:
- the v2 specific binary protocol - I don't quite see how we could test
  that without writing C
- version error checks - pg_regress/psql errors out in non-interactive
  mode if a connection fails to be established. This we could verify
  with a s simple tap test.

Coverage of the relevant files is a good bit higher afterwards. Although
our libpq coverage is generally pretty damn awful.

Regards,

Andres
>From d4b9fb485110a5a27d9f85eff23a8ffca550eaf2 Mon Sep 17 00:00:00 2001
From: Andres Freund 
Date: Wed, 20 Sep 2017 01:12:32 -0700
Subject: [PATCH 1/3] Add ability to force libpq to negotiate a specific
 version of the protocol.

Author: Andres Freund
Discussion: https://postgr.es/m/20170918095303.g766pdnvviqle...@alap3.anarazel.de
---
 src/interfaces/libpq/fe-connect.c | 13 -
 src/interfaces/libpq/libpq-int.h  |  3 +++
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/src/interfaces/libpq/fe-connect.c b/src/interfaces/libpq/fe-connect.c
index c580d91135..a9dd14d48b 100644
--- a/src/interfaces/libpq/fe-connect.c
+++ b/src/interfaces/libpq/fe-connect.c
@@ -323,6 +323,10 @@ static const internalPQconninfoOption PQconninfoOptions[] = {
 		"Target-Session-Attrs", "", 11, /* sizeof("read-write") = 11 */
 	offsetof(struct pg_conn, target_session_attrs)},
 
+	{"forced_protocol_version", "PGFORCEPROTOCOLVERSION", NULL, NULL,
+	 "Forced-version", "D", sizeof("Forced-version"),
+	offsetof(struct pg_conn, forced_protocol_version)},
+
 	/* Terminating entry --- MUST BE LAST */
 	{NULL, NULL, NULL, NULL,
 	NULL, NULL, 0}
@@ -1803,7 +1807,14 @@ connectDBStart(PGconn *conn)
 	 */
 	conn->whichhost = 0;
 	conn->addr_cur = conn->connhost[0].addrlist;
-	conn->pversion = PG_PROTOCOL(3, 0);
+	if (conn->forced_protocol_version != NULL)
+	{
+		conn->pversion = atoi(conn->forced_protocol_version);
+	}
+	else
+	{
+		conn->pversion = PG_PROTOCOL(3, 0);
+	}
 	conn->send_appname = true;
 	conn->status = CONNECTION_NEEDED;
 
diff --git a/src/interfaces/libpq/libpq-int.h b/src/interfaces/libpq/libpq-int.h
index 42913604e3..7bfc09ec71 100644
--- a/src/interfaces/libpq/libpq-int.h
+++ b/src/interfaces/libpq/libpq-int.h
@@ -364,6 +364,9 @@ struct pg_conn
 	/* Type of connection to make.  Possible values: any, read-write. */
 	char	   *target_session_attrs;
 
+	char	   *forced_protocol_version; /* for testing: force protocol to a
+		  * specific version */
+
 	/* Optional file to write trace info to */
 	FILE	   *Pfdebug;
 
-- 
2.14.1.536.g6867272d5b.dirty

>From da43188afcf150213212c6c419c5c87b003feb65 Mon Sep 17 00:00:00 2001
From: Andres Freund 
Date: Wed, 20 Sep 2017 01:10:17 -0700
Subject: [PATCH 2/3] Add minimal v2 protocol regression tests.

Author: Andres Freund
Discussion: https://postgr.es/m/20170918095303.g766pdnvviqle...@alap3.anarazel.de
---
 src/test/regress/expected/protocol.out | 252 +
 src/test/regress/parallel_schedule |   2 +-
 src/test/regress/serial_schedule   |   1 +
 src/test/regress/sql/protocol.sql  | 124 
 4 files changed, 378 insertions(+), 1 deletion(-)
 create mode 100644 src/test/regress/expected/protocol.out
 create mode 100644 src/test/regress/sql/protocol.sql

diff --git a/src/test/regress/expected/protocol.out b/src/test/regress/expected/protocol.out
new file mode 100644
index 00..75e183ba78
--- /dev/null
+++ b/src/test/regress/expected/protocol.out
@@ -0,0 +1,252 @@
+\set ON_ERROR_STOP 0
+-- Function that returns the protocol version, as required for the protocol
+CREATE OR REPLACE FUNCTION pg_protocol(major int, minor int)
+RETURNS int
+LANGUAGE SQL
+IMMUTABLE
+AS $$
+SELECT $1 << 16 | $2;
+$$;
+--
+-- first a few error checks about acceptance of various protocol versions
+--
+-- Can't execute failing tests these via psql -f / pg_regress, as they
+-- exit after 

Re: [HACKERS] Is it time to kill support for very old servers?

[Joshua D. Drake]

On 09/18/2017 04:54 AM, Robert Haas wrote:

On Mon, Sep 18, 2017 at 7:17 AM, Andres Freund  wrote:

Private:


Not so much.



Well, as much as the Internet is actually private:

https://ilccyberreport.files.wordpress.com/2013/06/nsa11.jpg

JD

;)


--
Command Prompt, Inc. || http://the.postgres.company/ || @cmdpromptinc

PostgreSQL Centered full stack support, consulting and development.
Advocate: @amplifypostgres || Learn: https://pgconf.us
* Unless otherwise stated, opinions are my own.   *


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Is it time to kill support for very old servers?

[Robert Haas]

On Mon, Sep 18, 2017 at 7:17 AM, Andres Freund  wrote:
> Private:

Not so much.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Is it time to kill support for very old servers?

[Michael Paquier]

On Mon, Sep 18, 2017 at 8:17 PM, Andres Freund  wrote:
> And now you missed the "same infrastructure" part.

I am sort of aware of that per the list of parameters at the top
fe-connect.c, thanks for the reminer :)
-- 
Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Is it time to kill support for very old servers?

[Andres Freund]

On September 18, 2017 4:15:31 AM PDT, Michael Paquier 
 wrote:
>On Mon, Sep 18, 2017 at 8:09 PM, Andres Freund 
>wrote:
>>
>>
>> On September 18, 2017 4:08:21 AM PDT, Michael Paquier
> wrote:
>>>On Mon, Sep 18, 2017 at 7:54 PM, Andres Freund 
>>>wrote:
>It seems to me that you are looking more for a connection parameter
>here.

 I'm not seeing a meaningful distinction here? Env vars and
>connection
>>>parameters are handled using the same framework in libpq.  And using
>>>the env var in the test would be better, because you'd only set one
>>>value - hard to do within our non TAP tests (i.e. in an existing
>psql,
>>>started by pg regress) otherwise.
>>>
>>>Or both? I don't really understand why an environment variable is
>>>better than a connection string. For the TAP tests, you could just
>set
>>>the base of the connection string once and you are done as well. See
>>>the SSL tests for example.
>>
>> Did you read what I wrote?
>
>Sorry, I missed the "non" with "TAP" tests. Having a connection
>parameter would still be low-cost in maintenance, so if you add that
>at the same time I won't complain.

Private:

And now you missed the "same infrastructure" part.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Is it time to kill support for very old servers?

[Michael Paquier]

On Mon, Sep 18, 2017 at 8:09 PM, Andres Freund  wrote:
>
>
> On September 18, 2017 4:08:21 AM PDT, Michael Paquier 
>  wrote:
>>On Mon, Sep 18, 2017 at 7:54 PM, Andres Freund 
>>wrote:
It seems to me that you are looking more for a connection parameter
here.
>>>
>>> I'm not seeing a meaningful distinction here? Env vars and connection
>>parameters are handled using the same framework in libpq.  And using
>>the env var in the test would be better, because you'd only set one
>>value - hard to do within our non TAP tests (i.e. in an existing psql,
>>started by pg regress) otherwise.
>>
>>Or both? I don't really understand why an environment variable is
>>better than a connection string. For the TAP tests, you could just set
>>the base of the connection string once and you are done as well. See
>>the SSL tests for example.
>
> Did you read what I wrote?

Sorry, I missed the "non" with "TAP" tests. Having a connection
parameter would still be low-cost in maintenance, so if you add that
at the same time I won't complain.
-- 
Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Is it time to kill support for very old servers?

[Andres Freund]

On September 18, 2017 4:08:21 AM PDT, Michael Paquier 
 wrote:
>On Mon, Sep 18, 2017 at 7:54 PM, Andres Freund 
>wrote:
>>>It seems to me that you are looking more for a connection parameter
>>>here.
>>
>> I'm not seeing a meaningful distinction here? Env vars and connection
>parameters are handled using the same framework in libpq.  And using
>the env var in the test would be better, because you'd only set one
>value - hard to do within our non TAP tests (i.e. in an existing psql,
>started by pg regress) otherwise.
>
>Or both? I don't really understand why an environment variable is
>better than a connection string. For the TAP tests, you could just set
>the base of the connection string once and you are done as well. See
>the SSL tests for example.

Did you read what I wrote?
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Is it time to kill support for very old servers?

[Michael Paquier]

On Mon, Sep 18, 2017 at 7:54 PM, Andres Freund  wrote:
>>It seems to me that you are looking more for a connection parameter
>>here.
>
> I'm not seeing a meaningful distinction here? Env vars and connection 
> parameters are handled using the same framework in libpq.  And using the env 
> var in the test would be better, because you'd only set one value - hard to 
> do within our non TAP tests (i.e. in an existing psql, started by pg regress) 
> otherwise.

Or both? I don't really understand why an environment variable is
better than a connection string. For the TAP tests, you could just set
the base of the connection string once and you are done as well. See
the SSL tests for example.
-- 
Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Is it time to kill support for very old servers?

[Andres Freund]

On September 18, 2017 3:50:17 AM PDT, Michael Paquier 
 wrote:
>On Mon, Sep 18, 2017 at 6:53 PM, Andres Freund 
>wrote:
>> On 2017-09-13 23:39:21 -0400, Tom Lane wrote:
>>> The real problem in this area, to my mind, is that we're not testing
>that
>>> code --- either end of it --- in any systematic way.  If it's broken
>it
>>> could take us quite a while to notice.
>>
>> Independent of the thrust of my question - why aren't we adding a
>> 'force-v2' option to libpq?  A test that basically does something
>like
>> postgres[22923][1]=# \setenv PGFORCEV2 1
>> postgres[22923][1]=# \c
>> You are now connected to database "postgres" as user "andres".
>> postgres[22924][1]=>
>> seems easy enough to add, in fact I tested the above.
>>
>> And the protocol coverage of the v2 protocol seems small enough that
>a
>> single not too large file ought to cover most if it quite easily.
>
>It seems to me that you are looking more for a connection parameter
>here.

I'm not seeing a meaningful distinction here? Env vars and connection 
parameters are handled using the same framework in libpq.  And using the env 
var in the test would be better, because you'd only set one value - hard to do 
within our non TAP tests (i.e. in an existing psql, started by pg regress) 
otherwise.

Andres
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Is it time to kill support for very old servers?

[Michael Paquier]

On Mon, Sep 18, 2017 at 6:53 PM, Andres Freund  wrote:
> On 2017-09-13 23:39:21 -0400, Tom Lane wrote:
>> The real problem in this area, to my mind, is that we're not testing that
>> code --- either end of it --- in any systematic way.  If it's broken it
>> could take us quite a while to notice.
>
> Independent of the thrust of my question - why aren't we adding a
> 'force-v2' option to libpq?  A test that basically does something like
> postgres[22923][1]=# \setenv PGFORCEV2 1
> postgres[22923][1]=# \c
> You are now connected to database "postgres" as user "andres".
> postgres[22924][1]=>
> seems easy enough to add, in fact I tested the above.
>
> And the protocol coverage of the v2 protocol seems small enough that a
> single not too large file ought to cover most if it quite easily.

It seems to me that you are looking more for a connection parameter here.
-- 
Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Is it time to kill support for very old servers?

[Andres Freund]

On 2017-09-13 23:39:21 -0400, Tom Lane wrote:
> The real problem in this area, to my mind, is that we're not testing that
> code --- either end of it --- in any systematic way.  If it's broken it
> could take us quite a while to notice.

Independent of the thrust of my question - why aren't we adding a
'force-v2' option to libpq?  A test that basically does something like
postgres[22923][1]=# \setenv PGFORCEV2 1
postgres[22923][1]=# \c
You are now connected to database "postgres" as user "andres".
postgres[22924][1]=>
seems easy enough to add, in fact I tested the above.

And the protocol coverage of the v2 protocol seems small enough that a
single not too large file ought to cover most if it quite easily.

Greetings,

Andres Freund


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Is it time to kill support for very old servers?

[Robert Haas]

On Wed, Sep 13, 2017 at 11:39 PM, Tom Lane  wrote:
>>> One small problem with cutting libpq's V2 support is that the server's
>>> report_fork_failure_to_client() function still sends a V2-style message.
>
>> We should really fix that so it reports the error as a v3 message,
>> independent of ripping out libpq-fe support for v2.
>
> It might be reasonable to do that, but libpq would have to be prepared
> for the other case for many years to come :-(

Well, let's get that much done anyway.  I'm not 100% sure whether the
time has come to kill v2 with fire, but doing the things that have
been done first has got to be a good idea either way.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Is it time to kill support for very old servers?

[Andres Freund]

Hi,

On 2017-09-13 23:39:21 -0400, Tom Lane wrote:
> Andres Freund  writes:
> > Re-upping this topic.
> 
> > On 2016-10-07 10:06:07 -0400, Tom Lane wrote:
> >> In the same line, maybe we should kill libpq's support for V2 protocol
> >> (which would make the cutoff 7.4).  And maybe the server's support too,
> >> though that wouldn't save very much code.  The argument for cutting this
> >> isn't so much that we would remove lots of code as that we're removing
> >> code that never gets tested, at least not by us.
> 
> > I'd like to do this in the not too far away future for at least the
> > backend. There's enough not particularly pretty code to deal with v2
> > that that'd be worthwhile.
> 
> Hm, I don't recall that there's very much on the server side that could be
> saved --- what's incurring your ire, exactly?

In this specific instance it's SendRowDescriptionMessage() for a queries
returning a lot of columns that execute fast. The additional branches
due to the if (proto >= 3) conditionals are noticeable. It's easy enough
to fix by having two for() for the two cases. The added code is annoying
but bearable, what actually concerns me is that it's really hard to test
the v2 support.


> >> One small problem with cutting libpq's V2 support is that the server's
> >> report_fork_failure_to_client() function still sends a V2-style message.
> 
> > We should really fix that so it reports the error as a v3 message,
> > independent of ripping out libpq-fe support for v2.
> 
> It might be reasonable to do that, but libpq would have to be prepared
> for the other case for many years to come :-(

Right. But there seems pretty much no way to get around that. At least
none that I can see?  It might be worthwhile and more testable to add a
special case V2 handling for the oom-fork case, but still.


> The real problem in this area, to my mind, is that we're not testing that
> code --- either end of it --- in any systematic way.  If it's broken it
> could take us quite a while to notice.

Yea, that concerns me a lot too (see above).

Greetings,

Andres Freund


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Is it time to kill support for very old servers?

[Tom Lane]

Andres Freund  writes:
> Re-upping this topic.

> On 2016-10-07 10:06:07 -0400, Tom Lane wrote:
>> In the same line, maybe we should kill libpq's support for V2 protocol
>> (which would make the cutoff 7.4).  And maybe the server's support too,
>> though that wouldn't save very much code.  The argument for cutting this
>> isn't so much that we would remove lots of code as that we're removing
>> code that never gets tested, at least not by us.

> I'd like to do this in the not too far away future for at least the
> backend. There's enough not particularly pretty code to deal with v2
> that that'd be worthwhile.

Hm, I don't recall that there's very much on the server side that could be
saved --- what's incurring your ire, exactly?

>> One small problem with cutting libpq's V2 support is that the server's
>> report_fork_failure_to_client() function still sends a V2-style message.

> We should really fix that so it reports the error as a v3 message,
> independent of ripping out libpq-fe support for v2.

It might be reasonable to do that, but libpq would have to be prepared
for the other case for many years to come :-(

The real problem in this area, to my mind, is that we're not testing that
code --- either end of it --- in any systematic way.  If it's broken it
could take us quite a while to notice.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Is it time to kill support for very old servers?

[Andres Freund]

Hi,

Re-upping this topic.

On 2016-10-07 10:06:07 -0400, Tom Lane wrote:
> In the same line, maybe we should kill libpq's support for V2 protocol
> (which would make the cutoff 7.4).  And maybe the server's support too,
> though that wouldn't save very much code.  The argument for cutting this
> isn't so much that we would remove lots of code as that we're removing
> code that never gets tested, at least not by us.

I'd like to do this in the not too far away future for at least the
backend. There's enough not particularly pretty code to deal with v2
that that'd be worthwhile.


> One small problem with cutting libpq's V2 support is that the server's
> report_fork_failure_to_client() function still sends a V2-style message.
> We could change that in HEAD, certainly, but we don't really want modern
> libpq unable to parse such a message from an older server.  Possibly we
> could handle that specific case with a little special-purpose code and
> still be able to take out most of fe-protocol2.c.

We should really fix that so it reports the error as a v3 message,
independent of ripping out libpq-fe support for v2.

Greetings,

Andres Freund


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Is it time to kill support for very old servers?

[Robert Haas]

On Tue, Oct 11, 2016 at 11:34 AM, Heikki Linnakangas  wrote:
> On 10/11/2016 08:23 PM, Tom Lane wrote:
>> Not sure where to go from here, but the idea of dropping V2 support
>> is seeming attractive again.  Or we could just continue the policy
>> of benign neglect.
>
> Let's drop it.

I agree.  The evidence in Tom's latest email suggests that getting
this to a point where it can be tested will be more work than
anybody's likely to want to put in, and the return on investment
doesn't seem likely to be good.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Is it time to kill support for very old servers?

[Tom Lane]

I wrote:
> pg_dump alleges support for dumping from servers back to 7.0.  Would v10
> be a good time to remove some of that code?  It's getting harder and
> harder to even compile those ancient branches, let alone get people to
> test against them (cf. 4806f26f9).  My initial thought is to cut support
> for pre-7.3 or maybe pre-7.4 servers, as that would allow removal of
> support for cases where the server lacks schemas or pg_depend, each of
> which requires a fair deal of klugery in pg_dump.

Per subsequent discussion, we should use a round number as the version
cutoff, so attached is a patch that removes pg_dump/pg_dumpall support
for dumping from servers before 8.0.  This eliminates circa 1500 lines
of code, or about 4% of the existing code in src/bin/pg_dump/.  So it's
not a huge savings, but it eliminates a lot of hard-to-test cases.

I (think I) did not do anything that would damage pg_restore's ability to
read dump archives produced by pre-8.0 versions.  I'm pretty hesitant to
remove that code since (a) there's not all that much of it, and (b) it's
easy to imagine scenarios where an old backup dump is all someone's got.
However, that's another set of cases that's darn hard to test, so it's
somewhat questionable whether we may have broken it already.

Comments, objections?

regards, tom lane



pg_dump-drop-old-server-support.patch.gz
Description: pg_dump-drop-old-server-support.patch.gz

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Is it time to kill support for very old servers?

[Heikki Linnakangas]

On 10/11/2016 08:23 PM, Tom Lane wrote:

Not sure where to go from here, but the idea of dropping V2 support
is seeming attractive again.  Or we could just continue the policy
of benign neglect.


Let's drop it.

- Heikki



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Is it time to kill support for very old servers?

[Tom Lane]

Robert Haas  writes:
> On Fri, Oct 7, 2016 at 11:34 AM, Tom Lane  wrote:
>> The problem with letting it just sit there is that we're not, in fact,
>> testing it.  If we take the above argument seriously then we should
>> provide some way to configure libpq to prefer V2 and run regression
>> tests in that mode.  Otherwise, if/when we break it, we'll never know it
>> till we get field reports.

> I agree with that.  I think it would be fine to keep V2 support if
> somebody wants to do the work to let us have adequate test coverage,
> but if nobody volunteers I think we might as well rip it out.  I don't
> particularly enjoy committing things only to be told that they've
> broken something I can't test without unreasonable effort.

I experimented with this and found out that a majority of the regression
tests fall over, because the error messages come out formatted differently
when using V2.  You don't get separate DETAIL or HINT fields, nor cursor
positions, etc.  So there's boatloads of silly diffs like this:

***
*** 69,75 
  INSERT INTO testschema.atable VALUES(3);  -- ok
  INSERT INTO testschema.atable VALUES(1);  -- fail (checks index)
  ERROR:  duplicate key value violates unique constraint "anindex"
- DETAIL:  Key (column1)=(1) already exists.
  SELECT COUNT(*) FROM testschema.atable;   -- checks heap
   count 
  ---
--- 69,74 

Some of the tests have harder-to-ignore failures because protocol V2
had no way to recover from a failure during COPY IN, short of aborting
the connection:

--- 34,42 
  -- missing data: should fail
  COPY x from stdin;
  ERROR:  invalid input syntax for integer: ""
! FATAL:  terminating connection because protocol synchronization was lost
  COPY x from stdin;
! server closed the connection unexpectedly
!   This probably means the server terminated abnormally
!   before or while processing the request.
! connection to server was lost


At this point I'm feeling pretty discouraged about testability of V2.
I can't see us maintaining a variant regression test suite that would
accommodate these issues.  So the easy idea of "build with some extra
#define and then run the usual regression tests" is out.

Now, we hardly need the entire regression suite to provide adequate
coverage of V2 protocol.  You could imagine a small dedicated test
that just checks basic commands, errors, notices, COPY.  The problem
is that we'd need infrastructure in either the backend or libpq to
dynamically force use of V2 for that test, and that's work that I for
one don't really care to put in.

Not sure where to go from here, but the idea of dropping V2 support
is seeming attractive again.  Or we could just continue the policy
of benign neglect.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Is it time to kill support for very old servers?

[Craig Ringer]

On 10 October 2016 at 10:45, Jim Nasby  wrote:
> On 10/7/16 1:08 PM, Steve Crawford wrote:
>>
>> This is effectively a 5-year upgrade "grace period" *after* the EOL date
>> of a given version which seems plenty generous.
>
>
> IMHO we need to be careful here. It's not at all unusual to see servers
> running versions that are *far* older than that. It's certainly
> understandable that we're not actively supporting those versions any more,
> but we also don't want people to effectively be stranded on them because
> they can't even get the data out and back into a newer version. So I think
> pg_dump at least should try to support as far back as we can without jumping
> to lots of hoops in code. I think moving the limit to 8.0 is fine, but I'm
> not so comfortable with making that limit 9.1.

The oldest I deal with is 8.2, and that's enough of an aberration that
expecting them to go via 9.6 isn't wholly unreasonable. I agree 9.0 is
way too far.


-- 
 Craig Ringer   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Is it time to kill support for very old servers?

[Jim Nasby]

On 10/7/16 1:08 PM, Steve Crawford wrote:

This is effectively a 5-year upgrade "grace period" *after* the EOL date
of a given version which seems plenty generous.


IMHO we need to be careful here. It's not at all unusual to see servers 
running versions that are *far* older than that. It's certainly 
understandable that we're not actively supporting those versions any 
more, but we also don't want people to effectively be stranded on them 
because they can't even get the data out and back into a newer version. 
So I think pg_dump at least should try to support as far back as we can 
without jumping to lots of hoops in code. I think moving the limit to 
8.0 is fine, but I'm not so comfortable with making that limit 9.1.

--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)   mobile: 512-569-9461


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Is it time to kill support for very old servers?

[Steve Crawford]

This thread gets me thinking about the definition of "support." While
support in practice seems to primarily relate to fixes/updates to the
supported version itself it could just as well apply to interoperability
support by newer versions.

Given that the standard PostgreSQL upgrade process involves upgrading
clients first and using pg_dump from the newer version, it is reasonable to
assume that the clients/utilities for a given version would support
interacting with any prior version that was not EOL at the time the new
major version is released.

In other words, 9.6 was released last month, the same month that 9.1 was
EOL, so 9.6 clients should work with 9.1 through 9.6 servers but from my
perspective there is no need to *guarantee* that 10 would do so. The
standard caveats apply. A new version *might* work for an unsupported older
version but no assurance is offered.

This is effectively a 5-year upgrade "grace period" *after* the EOL date of
a given version which seems plenty generous.

Defining the term of backward compatibility support might be useful in the
future when these types of questions arise.

Cheers,
Steve






On Fri, Oct 7, 2016 at 9:06 AM, Tom Lane  wrote:

> Robert Haas  writes:
> > On Fri, Oct 7, 2016 at 11:34 AM, Tom Lane  wrote:
> >> Greg Stark  writes:
> >>> For another there may be binary-only applications or drivers out there
> >>> that are using V2 for whatever reason.
>
> >> The problem with letting it just sit there is that we're not, in fact,
> >> testing it.  If we take the above argument seriously then we should
> >> provide some way to configure libpq to prefer V2 and run regression
> >> tests in that mode.  Otherwise, if/when we break it, we'll never know it
> >> till we get field reports.
>
> > I agree with that.  I think it would be fine to keep V2 support if
> > somebody wants to do the work to let us have adequate test coverage,
> > but if nobody volunteers I think we might as well rip it out.  I don't
> > particularly enjoy committing things only to be told that they've
> > broken something I can't test without unreasonable effort.
>
> When I wrote the above I was thinking of an essentially user-facing
> libpq feature, similar to the one JDBC has, to force use of V2 protocol.
> But actually, for testing purposes, I don't think that's what we want.
> Any such feature would fail to exercise libpq's logic for falling back
> from V3 to V2 when it connects to an old server, which is surely something
> we'd like to test without actually having a pre-7.4 server at hand.
>
> So what I'm thinking is it'd be sufficient to do something like
> this in pqcomm.h:
>
> +#ifndef FORCE_OLD_PROTOCOL
>  #define PG_PROTOCOL_LATEST PG_PROTOCOL(3,0)
> +#else /* make like a pre-7.4 server for testing purposes */
> +#define PG_PROTOCOL_LATEST PG_PROTOCOL(2,0)
> +#endif
>
> which would cause the server to reject 3.0 requests just as if it were
> ancient.  Then we could test with that #define, maybe have a buildfarm
> critter doing it.  (This might break pqmq.c though, so we might need
> to work slightly harder than this.)
>
> Also, I realized while perusing this that the server still has support
> for protocol 1.0 (!).  That's *definitely* dead code.  There's not much
> of it, but still, I'd rather rip it out than continue to pretend it's
> supported.
>
> regards, tom lane
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

Re: [HACKERS] Is it time to kill support for very old servers?

[Tom Lane]

Robert Haas  writes:
> On Fri, Oct 7, 2016 at 11:34 AM, Tom Lane  wrote:
>> Greg Stark  writes:
>>> For another there may be binary-only applications or drivers out there
>>> that are using V2 for whatever reason.

>> The problem with letting it just sit there is that we're not, in fact,
>> testing it.  If we take the above argument seriously then we should
>> provide some way to configure libpq to prefer V2 and run regression
>> tests in that mode.  Otherwise, if/when we break it, we'll never know it
>> till we get field reports.

> I agree with that.  I think it would be fine to keep V2 support if
> somebody wants to do the work to let us have adequate test coverage,
> but if nobody volunteers I think we might as well rip it out.  I don't
> particularly enjoy committing things only to be told that they've
> broken something I can't test without unreasonable effort.

When I wrote the above I was thinking of an essentially user-facing
libpq feature, similar to the one JDBC has, to force use of V2 protocol.
But actually, for testing purposes, I don't think that's what we want.
Any such feature would fail to exercise libpq's logic for falling back
from V3 to V2 when it connects to an old server, which is surely something
we'd like to test without actually having a pre-7.4 server at hand.

So what I'm thinking is it'd be sufficient to do something like
this in pqcomm.h:

+#ifndef FORCE_OLD_PROTOCOL
 #define PG_PROTOCOL_LATEST PG_PROTOCOL(3,0)
+#else /* make like a pre-7.4 server for testing purposes */
+#define PG_PROTOCOL_LATEST PG_PROTOCOL(2,0)
+#endif

which would cause the server to reject 3.0 requests just as if it were
ancient.  Then we could test with that #define, maybe have a buildfarm
critter doing it.  (This might break pqmq.c though, so we might need
to work slightly harder than this.)

Also, I realized while perusing this that the server still has support
for protocol 1.0 (!).  That's *definitely* dead code.  There's not much
of it, but still, I'd rather rip it out than continue to pretend it's
supported.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Is it time to kill support for very old servers?

[Robert Haas]

On Fri, Oct 7, 2016 at 11:34 AM, Tom Lane  wrote:
> Greg Stark  writes:
>> On Fri, Oct 7, 2016 at 3:06 PM, Tom Lane  wrote:
>>> In the same line, maybe we should kill libpq's support for V2 protocol
>>> (which would make the cutoff 7.4).  And maybe the server's support too,
>>> though that wouldn't save very much code.  The argument for cutting this
>>> isn't so much that we would remove lots of code as that we're removing
>>> code that never gets tested, at least not by us.
>
>> Somehow removing the whole protocol support seems a bit different to
>> me than removing pg_dump logic. For one it's nice to be able to run a
>> modern psql against old servers so you can run a benchmark script.
>
> Yeah, but surely pre-7.4 servers are no longer of much interest for that;
> or if you want historical results you should also use a matching libpq.
>
>> For another there may be binary-only applications or drivers out there
>> that are using V2 for whatever reason.
>
> The problem with letting it just sit there is that we're not, in fact,
> testing it.  If we take the above argument seriously then we should
> provide some way to configure libpq to prefer V2 and run regression
> tests in that mode.  Otherwise, if/when we break it, we'll never know it
> till we get field reports.

I agree with that.  I think it would be fine to keep V2 support if
somebody wants to do the work to let us have adequate test coverage,
but if nobody volunteers I think we might as well rip it out.  I don't
particularly enjoy committing things only to be told that they've
broken something I can't test without unreasonable effort.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Is it time to kill support for very old servers?

[Tom Lane]

Greg Stark  writes:
> On Fri, Oct 7, 2016 at 3:06 PM, Tom Lane  wrote:
>> In the same line, maybe we should kill libpq's support for V2 protocol
>> (which would make the cutoff 7.4).  And maybe the server's support too,
>> though that wouldn't save very much code.  The argument for cutting this
>> isn't so much that we would remove lots of code as that we're removing
>> code that never gets tested, at least not by us.

> Somehow removing the whole protocol support seems a bit different to
> me than removing pg_dump logic. For one it's nice to be able to run a
> modern psql against old servers so you can run a benchmark script.

Yeah, but surely pre-7.4 servers are no longer of much interest for that;
or if you want historical results you should also use a matching libpq.

> For another there may be binary-only applications or drivers out there
> that are using V2 for whatever reason.

The problem with letting it just sit there is that we're not, in fact,
testing it.  If we take the above argument seriously then we should
provide some way to configure libpq to prefer V2 and run regression
tests in that mode.  Otherwise, if/when we break it, we'll never know it
till we get field reports.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Is it time to kill support for very old servers?

[Greg Stark]

On Fri, Oct 7, 2016 at 3:06 PM, Tom Lane  wrote:
> pg_dump alleges support for dumping from servers back to 7.0.  Would v10
> be a good time to remove some of that code?  It's getting harder and
> harder to even compile those ancient branches, let alone get people to
> test against them (cf. 4806f26f9).  My initial thought is to cut support
> for pre-7.3 or maybe pre-7.4 servers, as that would allow removal of
> support for cases where the server lacks schemas or pg_depend, each of
> which requires a fair deal of klugery in pg_dump.

I might be expected to be the holdout here but it seems sensible to
me. Removing code in pg_dump to deal with lacking schemas and
pg_depend seems like a major simplification.


> In the same line, maybe we should kill libpq's support for V2 protocol
> (which would make the cutoff 7.4).  And maybe the server's support too,
> though that wouldn't save very much code.  The argument for cutting this
> isn't so much that we would remove lots of code as that we're removing
> code that never gets tested, at least not by us.

If it's testing we're concerned about IIRC the current servers can be
arm-twisted into speaking V2 protocol. So it should be possible to
test both modern servers and modern pg_dump using V2 protocol with a
simple tweak.

Somehow removing the whole protocol support seems a bit different to
me than removing pg_dump logic. For one it's nice to be able to run a
modern psql against old servers so you can run a benchmark script. For
another there may be binary-only applications or drivers out there
that are using V2 for whatever reason.


-- 
greg


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Is it time to kill support for very old servers?

[Robert Haas]

On Fri, Oct 7, 2016 at 10:06 AM, Tom Lane  wrote:
> pg_dump alleges support for dumping from servers back to 7.0.  Would v10
> be a good time to remove some of that code?  It's getting harder and
> harder to even compile those ancient branches, let alone get people to
> test against them (cf. 4806f26f9).  My initial thought is to cut support
> for pre-7.3 or maybe pre-7.4 servers, as that would allow removal of
> support for cases where the server lacks schemas or pg_depend, each of
> which requires a fair deal of klugery in pg_dump.

It's been a long time since I've seen any 7.x versions in the wild,
and the pg_dump stuff is a nuisance to maintain.  +1 for dropping
support for anything pre-7.4.  Anybody who is upgrading from 7.3 to 10
isn't likely to want to do it in one swing anyway.  In the real world,
few upgrades span 14 major versions.

> In the same line, maybe we should kill libpq's support for V2 protocol
> (which would make the cutoff 7.4).  And maybe the server's support too,
> though that wouldn't save very much code.  The argument for cutting this
> isn't so much that we would remove lots of code as that we're removing
> code that never gets tested, at least not by us.
>
> One small problem with cutting libpq's V2 support is that the server's
> report_fork_failure_to_client() function still sends a V2-style message.
> We could change that in HEAD, certainly, but we don't really want modern
> libpq unable to parse such a message from an older server.  Possibly we
> could handle that specific case with a little special-purpose code and
> still be able to take out most of fe-protocol2.c.

I definitely think we can't remove client support for anything that
modern servers still send, even if we change 10devel so that it no
longer does so.   I think we have to at least wait until all versions
that might send a message are EOL before removing client-side support
for it -- and maybe a bit longer than that.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Is it time to kill support for very old servers?

[Magnus Hagander]

On Fri, Oct 7, 2016 at 4:06 PM, Tom Lane  wrote:

> pg_dump alleges support for dumping from servers back to 7.0.  Would v10
> be a good time to remove some of that code?  It's getting harder and
> harder to even compile those ancient branches, let alone get people to
> test against them (cf. 4806f26f9).  My initial thought is to cut support
> for pre-7.3 or maybe pre-7.4 servers, as that would allow removal of
> support for cases where the server lacks schemas or pg_depend, each of
> which requires a fair deal of klugery in pg_dump.
>

+1 for doing it, and also picking a version that's "easily explainable". If
we can say "now we support back to 8.0" that's a lot better than saying 8.1
or 7.4.



> In the same line, maybe we should kill libpq's support for V2 protocol
> (which would make the cutoff 7.4).  And maybe the server's support too,
> though that wouldn't save very much code.  The argument for cutting this
> isn't so much that we would remove lots of code as that we're removing
> code that never gets tested, at least not by us.
>

Which is a pretty strong argument in itself.



> One small problem with cutting libpq's V2 support is that the server's
> report_fork_failure_to_client() function still sends a V2-style message.
> We could change that in HEAD, certainly, but we don't really want modern
> libpq unable to parse such a message from an older server.  Possibly we
> could handle that specific case with a little special-purpose code and
> still be able to take out most of fe-protocol2.c.
>
> Thoughts?
>

I agree we want the new libpq to be able to deal with that one from old
versions, because 9.6 isn't really old yet. We *should* probably change it
in head for the future anyway, but that means we have to keep it around in
libpq for quite a long while anyway.

Unless the special purpose code becomes long and complicated, I think
that's the best way to do it.

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

[HACKERS] Is it time to kill support for very old servers?

[Tom Lane]

pg_dump alleges support for dumping from servers back to 7.0.  Would v10
be a good time to remove some of that code?  It's getting harder and
harder to even compile those ancient branches, let alone get people to
test against them (cf. 4806f26f9).  My initial thought is to cut support
for pre-7.3 or maybe pre-7.4 servers, as that would allow removal of
support for cases where the server lacks schemas or pg_depend, each of
which requires a fair deal of klugery in pg_dump.

In the same line, maybe we should kill libpq's support for V2 protocol
(which would make the cutoff 7.4).  And maybe the server's support too,
though that wouldn't save very much code.  The argument for cutting this
isn't so much that we would remove lots of code as that we're removing
code that never gets tested, at least not by us.

One small problem with cutting libpq's V2 support is that the server's
report_fork_failure_to_client() function still sends a V2-style message.
We could change that in HEAD, certainly, but we don't really want modern
libpq unable to parse such a message from an older server.  Possibly we
could handle that specific case with a little special-purpose code and
still be able to take out most of fe-protocol2.c.

Thoughts?

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers