On Sun, Jul 17, 2016 at 3:43 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Establish conventions about global object names used in regression tests.
> require some rethinking of exactly what we want to test, whereas the intent
> of this patch is just to hit all the cases in which the needed renamings
> are cosmetic.
I gather that this patch was intended to be cosmetic and mechanical.
Why, then, did it result in a certain amount of seemingly
more-than-cosmetic test output changes for certain ecpg tests? For
example:
-[NO_PID]: ECPGconnect: opening database <DEFAULT> on localhost port
<DEFAULT> for user connectdb
+[NO_PID]: ECPGconnect: opening database <DEFAULT> on localhost port
<DEFAULT> for user regress_ecpg_user2
+[NO_PID]: sqlca: code: 0, state: 00000
+[NO_PID]: ECPGconnect: could not open database: FATAL: database
"regress_ecpg_user2" does not exist
I'm asking about this because I find that "make installcheck-world"
sometimes fails at this point when run against my local installation
-- the test "test connect/test" reliably fails. This is with Valgrind,
though that's probably not relevant. My installation outputs
more-or-less the *original* expected output prior to this commit. In
other words, the two extra lines added by the patch no longer appear,
plus there is a very similar difference a bit later in the same diffs
file (we also fail to fail to connect to this database, if the test
output is to be believed).
It's as if there really was a "regress_ecpg_user2" database, even
though I have no reason to believe that there should be one, and see
no evidence that there ever was one beyond the failing test output. I
am not the first person to notice this exact "regress_ecpg_user2"
database issue [1]. Theoretically this could be a bug in the patch
that I'm testing, but that seems rather unlikely. Some kind of problem
with the test or some kind of environmental issue seem much more
likely.
[1] https://www.postgresql.org/message-id/1607.1503920376%40sss.pgh.pa.us
--
Peter Geoghegan
