Robert Haas <robertmh...@gmail.com> writes:
> On Fri, Oct 7, 2016 at 11:34 AM, Tom Lane <t...@sss.pgh.pa.us> 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
