Обсуждение: [HACKERS] 1 test fails in make installcheck-world - database"regress_ecpg_user2" does not exist
Hello Postgres Hackers,
I want to become more helpful to the project, reviewing more patches and starting to write more of my own - and one of the first steps is to get all the tests passing so I can confidently review patches. It almost worked...Then I typed "make installcheck" and all the tests passed again.
=======================
1 of 55 tests failed.
=======================
The differences that caused some tests to fail can be viewed in the
file "path/to/postgres/src/interfaces/ecpg/test/regression.diffs". A copy of the test summary that you see
above is saved in the file "path/to/postgres/src/interfaces/ecpg/test/regression.out".
1 of 55 tests failed.
=======================
The differences that caused some tests to fail can be viewed in the
file "path/to/postgres/src/interfaces/ecpg/test/regression.diffs". A copy of the test summary that you see
above is saved in the file "path/to/postgres/src/interfaces/ecpg/test/regression.out".
- [NO_PID]: ECPGconnect: could not open database: FATAL: database "regress_ecpg_user2" does not exist
Thanks for your help!
Ryan
Вложения
Ryan Murphy <ryanfmurphy@gmail.com> writes:
> And when I look at that diffs file, this is what I see:
> - [NO_PID]: ECPGconnect: could not open database: FATAL: database
> "regress_ecpg_user2" does not exist
> Why would this database not be getting created?
No, you're reading it backwards: the error is expected, but it's not
appearing in your results. I can duplicate this if I manually create
database "regress_ecpg_user2" before running ecpg's installcheck,
so I guess that's what you did. I can find no evidence that any
part of the PG regression tests creates such a database.
regards, tom lane
No, you're reading it backwards: the error is expected, but it's not
appearing in your results. I can duplicate this if I manually create
database "regress_ecpg_user2" before running ecpg's installcheck,
so I guess that's what you did. I can find no evidence that any
part of the PG regression tests creates such a database.
Thanks, that makes sense. However, when I go into my database
with psql and type `drop database regress_ecpg_user2;`, the
response is "ERROR: database "regress_ecpg_user2" does not exist".
So it seems either the tests are creating it somehow and then cleaning
it up (though I agree that I found no obvious evidence of that in the
codebase), or could I be looking in the wrong postgres install?
I think it's the same install though. I have my postgres installing into an
install_dir/ directory. Here's how I run configure:
#!/bin/sh
CFLAGS='-O0' ./configure \
--prefix=path/to/postgres/
--with-uuid=e2fs \
--enable-debug \
--with-perl
CFLAGS='-O0' ./configure \
--prefix=path/to/postgres/
--with-uuid=e2fs \
--enable-debug \
--with-perl
I did notice that the test seems to create a ROLE called regress_ecpg_user2:
$ git grep -n 'regress_ecpg_user2'
src/interfaces/ecpg/test/Makefile:78:REGRESS_OPTS = --dbname=ecpg1_regression,ecpg2_regression --create-role=regress_ecpg_user1,regress_ecpg_user2 $(EXTRA_REGRESS_OPTS)
src/interfaces/ecpg/test/Makefile:78:REGRESS_OPTS = --dbname=ecpg1_regression,ecpg2_regression --create-role=regress_ecpg_user1,regress_ecpg_user2 $(EXTRA_REGRESS_OPTS)
...
Could that implicitly create a database too? I know that I somehow have a
database named after my username / postgres role "murftown".
I ran "make installcheck-world" again, and, the result is different this time -
a test called "misc_sanity" failed early on in the tests:
$ make installcheck-world
make -C src/test installcheck
make -C perl installcheck
make[2]: Nothing to be done for `installcheck'.
make -C regress installcheck
make -C src/test installcheck
make -C perl installcheck
make[2]: Nothing to be done for `installcheck'.
make -C regress installcheck
...
============== dropping database "regression" ==============
DROP DATABASE
============== creating database "regression" ==============
CREATE DATABASE
ALTER DATABASE
============== running regression test queries ==============
test tablespace ... ok
test boolean ... ok
test char ... ok
DROP DATABASE
============== creating database "regression" ==============
CREATE DATABASE
ALTER DATABASE
============== running regression test queries ==============
test tablespace ... ok
test boolean ... ok
test char ... ok
...
test regex ... ok
test oidjoins ... ok
test type_sanity ... ok
test opr_sanity ... ok
test misc_sanity ... FAILED
test comments ... ok
test expressions ... ok
test insert ... ok
test insert_conflict ... ok
test create_function_1 ... ok
test regex ... ok
test oidjoins ... ok
test type_sanity ... ok
test opr_sanity ... ok
test misc_sanity ... FAILED
test comments ... ok
test expressions ... ok
test insert ... ok
test insert_conflict ... ok
test create_function_1 ... ok
...
The old failure with the missing error message is gone from regression.diffs this time.
I've attached the new regression.diffs.
Best,
Ryan
Вложения
Ryan Murphy <ryanfmurphy@gmail.com> writes:
> I did notice that the test seems to create a ROLE called regress_ecpg_user2:
Right.
> Could that implicitly create a database too? I know that I somehow have a
> database named after my username / postgres role "murftown".
Maybe you've got some tool somewhere that automatically creates databases
for users? PG itself doesn't.
> I've attached the new regression.diffs.
Oh, huh, that's actually a bug in the misc_sanity test --- it is legit for
at least some rows in pg_shdepend to have zero dbid. That doesn't happen
when working in an empty installation, but yours evidently isn't. Thanks
for reporting it!
regards, tom lane
Thanks for reporting it!
My pleasure!
So the initial issue didn't happen the 2nd time. So if misc_sanity was the only test
failing then I guess my tests are working fine other than that. Sweet!
When I get a break from work I'll review some patches!
Best,
Ryan