Re: Buildfarm issues on specific machines

Andrew Dunstan <andrew(at)dunslane(dot)net> 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