Re: Cygwin PostgreSQL Regression Test Problems
От | Tom Lane |
---|---|
Тема | Re: Cygwin PostgreSQL Regression Test Problems |
Дата | |
Msg-id | 11518.979627521@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Cygwin PostgreSQL Regression Test Problems (Jason Tishler <Jason.Tishler@dothill.com>) |
Ответы |
Re: Cygwin PostgreSQL Regression Test Problems
|
Список | pgsql-ports |
Jason Tishler <Jason.Tishler@dothill.com> writes: > parallel group (7 tests): create_aggregate create_operator inherit triggers constraints create_misc create_index > constraints ... FAILED > triggers ... FAILED > create_misc ... FAILED > create_aggregate ... ok Can't tell much from this. What are the detail diffs (regression.diffs file?) > 2. I am unable to successfully run the regression tests on a NT 4.0 SP5 > machine with only 64 MB of physical memory and about 175 MB of swap space. > Other than lacking RAM and swap space, this machine is the "same" as other > NT/2000 machines which can successfully run the regression tests. > The tests usually hang during the "parallel group (18 tests)" test > right after numerology. By "hang," I mean that the original postmaster > is still running, but there are no postmaster children, and there are > some number of psql processes hanging around. Hm. You will have 18 backends firing up there, plus 18 psqls to drive 'em, and probably 18 shell subprocesses parenting the psqls. I wouldn't be too surprised at running out of memory --- but one would like to expect a more graceful failure than just hanging. What if anything shows up in the postmaster log? > 3. Once (or twice), I noticed that the plpgsql test failed. > Unfortunately, I didn't capture the precise output but I think that > postmaster was complaining about being unable to > mv <somepath>/pg_internal.init.<somepid> <somepath>/pg_internal.init > due to a permissions problem. Sorry, for being vague... Hm. The first backend to fire up after a vacuum will try to rebuild pg_internal.init, and then move it into place with /* * And rename the temp file to its final name, deleting any * previously-existing init file. */ if (rename(tempfilename, finalfilename) < 0) { elog(NOTICE, "Cannot rename init file %s to %s: %m\n\tContinuing anyway, but there's something wrong.", tempfilename,finalfilename); } In a parallel test it's possible that several backends would try to do this at about the same time, but that should be OK; we should end up with just one file from the last-to-finish backend. I think you have found another Cygwin bug :-( regards, tom lane
В списке pgsql-ports по дате отправления: