Skip site navigation (1) Skip section navigation (2)

Re: Cygwin PostgreSQL Regression Test Problems

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jason Tishler <Jason(dot)Tishler(at)dothill(dot)com>
Cc: pgsql-ports(at)postgresql(dot)org
Subject: Re: Cygwin PostgreSQL Regression Test Problems
Date: 2001-01-16 06:45:21
Message-ID: 11518.979627521@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-ports
Jason Tishler <Jason(dot)Tishler(at)dothill(dot)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

In response to

Responses

pgsql-ports by date

Next:From: Jason TishlerDate: 2001-01-16 14:35:14
Subject: Re: Cygwin PostgreSQL CVS Patch
Previous:From: Tom LaneDate: 2001-01-16 05:04:57
Subject: Re: Cygwin PostgreSQL CVS Patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group