Re: [HACKERS] [COMMITTERS] pgsql: Refactor flex and bison make rules
On 11/28/2012 11:03 PM, Tom Lane wrote: Jeremy Drake 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.) Looks like it was. Good catch. What's the best way to fix? Note that this problem was triggered by having a buildfarm buildroot path of length about 49 or 50. I'm lucky not to have triggered it myself. Do I need to add a check to limit the buildroot path length? cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [COMMITTERS] pgsql: Refactor flex and bison make rules
On Wed, 28 Nov 2012, Tom Lane wrote: > Jeremy Drake 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.) /usr/include/sys/un.h:char sun_path[108]; /* Path name. */ That seems to be it. This may be just the excuse I needed to set up dedicated users for my buildfarm animals. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [COMMITTERS] pgsql: Refactor flex and bison make rules
On Wed, 28 Nov 2012, Tom Lane wrote: > Andrew Dunstan writes: > > On 11/28/2012 02:14 PM, Alvaro Herrera wrote: > >> Okapi has been failing sporadically on ecpg, and I wonder if it's > >> related to this change. > > > Well, it looks like the make is broken and missing a clear dependency > > requirement. I think we need to ask Jeremy to turn off parallel build > > for okapi. > > Yeah, we already know that unpatched make 3.82 has got serious > parallelism bugs: > http://archives.postgresql.org/pgsql-hackers/2012-09/msg00397.php > > I wonder whether adding another .NOTPARALLEL directive would be a better > idea than insisting people get hold of patched versions. 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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [COMMITTERS] pgsql: Refactor flex and bison make rules
Jeremy Drake 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [COMMITTERS] pgsql: Refactor flex and bison make rules
Andrew Dunstan writes: > On 11/28/2012 06:19 PM, Tom Lane wrote: >> It appears to me that the case that okapi is hitting is specific to the >> ecpg preprocessor build rules, and indeed specific to the case where >> preproc.c needs to be rebuilt. A .NOTPARALLEL in ecpg/preproc/Makefile >> would probably be enough to fix it. (I'm a bit tempted to make the one >> already added to ecpg/Makefile conditional on the make version, as you >> suggest above, too.) > There is something odd about okapi, because my linux/gcc buildfarm > animal is using make 3.82 happily, with make_jobs = 4. Yeah, and nobody else has seen this either. It might just be that okapi has exactly the right number of processors with exactly the right speeds to make the failure a lot more probable. Or maybe there's something weird about Gentoo's version of make (wouldn't be the first time). Anyway, deparallelizing just the ecpg/preproc build would cost very little in build time, since it's totally dominated by the preproc.c and preproc.o build steps anyway. I'm inclined to just do it and see if the problem goes away. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [COMMITTERS] pgsql: Refactor flex and bison make rules
On 11/28/2012 06:19 PM, Tom Lane wrote: Peter Eisentraut writes: On 11/28/12 6:01 PM, Tom Lane wrote: I wonder whether adding another .NOTPARALLEL directive would be a better idea than insisting people get hold of patched versions. We could put ifeq ($(MAKE_VERSION),3.82) .NOTPARALLEL: endif into Makefile.global. I don't wish to go *that* far. Parallel make works fine for most of the tree in 3.82, and shutting it off would penalize developers a lot. It appears to me that the case that okapi is hitting is specific to the ecpg preprocessor build rules, and indeed specific to the case where preproc.c needs to be rebuilt. A .NOTPARALLEL in ecpg/preproc/Makefile would probably be enough to fix it. (I'm a bit tempted to make the one already added to ecpg/Makefile conditional on the make version, as you suggest above, too.) There is something odd about okapi, because my linux/gcc buildfarm animal is using make 3.82 happily, with make_jobs = 4. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [COMMITTERS] pgsql: Refactor flex and bison make rules
Peter Eisentraut writes: > On 11/28/12 6:01 PM, Tom Lane wrote: >> I wonder whether adding another .NOTPARALLEL directive would be a better >> idea than insisting people get hold of patched versions. > We could put > ifeq ($(MAKE_VERSION),3.82) > .NOTPARALLEL: > endif > into Makefile.global. I don't wish to go *that* far. Parallel make works fine for most of the tree in 3.82, and shutting it off would penalize developers a lot. It appears to me that the case that okapi is hitting is specific to the ecpg preprocessor build rules, and indeed specific to the case where preproc.c needs to be rebuilt. A .NOTPARALLEL in ecpg/preproc/Makefile would probably be enough to fix it. (I'm a bit tempted to make the one already added to ecpg/Makefile conditional on the make version, as you suggest above, too.) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [COMMITTERS] pgsql: Refactor flex and bison make rules
On 11/28/2012 06:01 PM, Tom Lane wrote: Andrew Dunstan writes: On 11/28/2012 02:14 PM, Alvaro Herrera wrote: Okapi has been failing sporadically on ecpg, and I wonder if it's related to this change. Well, it looks like the make is broken and missing a clear dependency requirement. I think we need to ask Jeremy to turn off parallel build for okapi. Yeah, we already know that unpatched make 3.82 has got serious parallelism bugs: http://archives.postgresql.org/pgsql-hackers/2012-09/msg00397.php I wonder whether adding another .NOTPARALLEL directive would be a better idea than insisting people get hold of patched versions. You mean in the preproc Makefile? Maybe. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [COMMITTERS] pgsql: Refactor flex and bison make rules
On 11/28/12 6:01 PM, Tom Lane wrote: > Andrew Dunstan writes: >> On 11/28/2012 02:14 PM, Alvaro Herrera wrote: >>> Okapi has been failing sporadically on ecpg, and I wonder if it's >>> related to this change. > >> Well, it looks like the make is broken and missing a clear dependency >> requirement. I think we need to ask Jeremy to turn off parallel build >> for okapi. > > Yeah, we already know that unpatched make 3.82 has got serious > parallelism bugs: > http://archives.postgresql.org/pgsql-hackers/2012-09/msg00397.php > > I wonder whether adding another .NOTPARALLEL directive would be a better > idea than insisting people get hold of patched versions. We could put ifeq ($(MAKE_VERSION),3.82) .NOTPARALLEL: endif into Makefile.global. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [COMMITTERS] pgsql: Refactor flex and bison make rules
Andrew Dunstan writes: > On 11/28/2012 02:14 PM, Alvaro Herrera wrote: >> Okapi has been failing sporadically on ecpg, and I wonder if it's >> related to this change. > Well, it looks like the make is broken and missing a clear dependency > requirement. I think we need to ask Jeremy to turn off parallel build > for okapi. Yeah, we already know that unpatched make 3.82 has got serious parallelism bugs: http://archives.postgresql.org/pgsql-hackers/2012-09/msg00397.php I wonder whether adding another .NOTPARALLEL directive would be a better idea than insisting people get hold of patched versions. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
