Re: assertion failure w/extended query protocol - Mailing list pgsql-hackers

From Robert Haas
Subject Re: assertion failure w/extended query protocol
Date
Msg-id CA+TgmoZtGdkC5dR0gEv6UHUo21c8hnyoYBrocyRE8YoJ-+Kwrg@mail.gmail.com
Whole thread Raw
In response to Re: assertion failure w/extended query protocol  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: assertion failure w/extended query protocol
List pgsql-hackers
On Fri, Oct 19, 2012 at 6:05 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> It's hard to visualize a use for this except for testing purposes, but
> that might be sufficient reason to have it.  One thing that would be
> pretty cool is to be able to run the regression tests in extended
> protocol.

Yes, indeed.  We came up with an even grottier hack to do this
internally for our fork and found a couple of bugs.  It appears, for
example, that the extended protocol exercises copyfuncs/equalfuncs
support a bit better than the simple protocol, and that's certainly
something that would be good to exercise regularly.

What I think is a bit insidious about this whole thing is that the
libpq documentation is not very clear about which functions use the
simple protocol and which ones use the extended protocol; it basically
treats that as an internal implementation detail.  And in theory it
should be, but there are significant performance differences between
the two and, as we're now finding out, they're not bug-compatible
either.  So +1 from me on finding a way to make the regression tests
run under the extended protocol.  If we do that, we should certainly
make sure the buildfarm does it regularly, because otherwise it's
quite likely to get broken again without anyone noticing.

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



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: pg_stat_lwlocks view - lwlocks statistics, round 2
Next
From: Andrew Dunstan
Date:
Subject: Re: assertion failure w/extended query protocol