Re: [COMMITTERS] pgsql: Refactor flex and bison make rules - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [COMMITTERS] pgsql: Refactor flex and bison make rules
Date
Msg-id 23496.1354161781@sss.pgh.pa.us
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Refactor flex and bison make rules  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [COMMITTERS] pgsql: Refactor flex and bison make rules  (Jeremy Drake <pgbuildfarm@jdrake.com>)
Re: [COMMITTERS] pgsql: Refactor flex and bison make rules  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
Jeremy Drake <pgbuildfarm@jdrake.com> writes:
> While we're talking about odd issues that only seem to happen on Okapi,
> does anyone know of anything I can do to diagnose the pg_upgrade failure
> on the 9.2 branch?  There are no rogue (non-buildfarm-related)
> postmaster/postgres processes running on the machine.

[ digs around ... ]  It looks like the failure is coming from here:
if (strlen(path) >= sizeof(unp->sun_path))    return EAI_FAIL;

What's the size of the sun_path member of struct sockaddr_un on your
machine?  I count 115 characters in your socket path ... maybe you
just need a less deeply nested test directory.

(If that is the problem, seems like we need to return something
more helpful than EAI_FAIL here.)
        regards, tom lane



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Bugs in CREATE/DROP INDEX CONCURRENTLY
Next
From: Tom Lane
Date:
Subject: Re: Bugs in CREATE/DROP INDEX CONCURRENTLY