Andrew Dunstan <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> potoroo [HEAD, 7.4]: lock file "/tmp/.s.PGSQL.65432.lock" already exists >> >> I'm not sure if this is a problem with a stale lock file left around >> from an old run, or if it happens because the machine is configured to >> try to build/test several branches in parallel. In any case, it might >> be worthwhile to try to hack the buildfarm script so that the Unix >> socket files are allocated in a per-branch scratch directory, not in >> /tmp. Or try to change pg_regress to use different port numbers for >> different branches?
> [ snip ] > So I think the right (and certainly simplest) thing is to make the tmp > port relative to the default port. I was thinking more along the lines of altering pg_regress to let the temp port be specified as a script parameter, though certainly there is nothing wrong with letting the Makefile supply 5xxxx as the normal value. I believe that if we do something like TEMP_PORT = 5$(default_port) check: pg_regress ... --temp_port=$(TEMP_PORT) then the port could be overridden without any source code hacks by "gmake TEMP_PORT=nnn check". In any case, there's still a question in my mind of exactly what is happening on potoroo. The times of the recent reports don't look like it's been configured to try to do multiple builds in parallel, so why is it failing like this? Has a temporary-installation postmaster somehow been left running somewhere? (The mere existence of the lock file would not cause this failure --- the PID in the lock file must correspond to an existing process matching the postmaster's UID, else it'll be deemed a stale lock file.) regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly