Re: [HACKERS] Failure on tapir / only 10 max connections?
Simon Riggs wrote: > On Fri, 2006-11-10 at 23:31 -0600, Jim C. Nasby wrote: > >> BTW, does make check log it's initdb output anywhere? It'd be handy if >> it did... > > They are logged in src/test/regress/log/initdb.log > but the make check failure message gives a relative filename, so you > have to know what the upper part of the path is to find it. > > It would be useful to have it say the full path for the failure log, so > it could be more easily located. > But for a buildfarm member this is scarcely necessary - the initdb output is included in the make check log. See http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=tapir&dt=2006-11-11%20080500&stg=check and search for 'initdb.log'. We have had a mechanism for limiting parallelism in make check for quite a while, and this too is supported by the buildfarm script - just set MAX_CONNECTIONS in the config. This is pretty much required for Cygwin, but can also be used for any resource starved machine. cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Failure on tapir / only 10 max connections?
On Fri, 2006-11-10 at 23:31 -0600, Jim C. Nasby wrote: > BTW, does make check log it's initdb output anywhere? It'd be handy if > it did... They are logged in src/test/regress/log/initdb.log but the make check failure message gives a relative filename, so you have to know what the upper part of the path is to find it. It would be useful to have it say the full path for the failure log, so it could be more easily located. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Failure on tapir / only 10 max connections?
"Jim C. Nasby" <[EMAIL PROTECTED]> writes: > Tapir appears to be failing because make check wants more than 10 > connections for testing. What I don't understand is why it's being > limited to 10. Your SysV IPC limits are too small --- apparently it's not so much shared memory as semaphores that are the problem. See the FreeBSD-specific notes in http://developer.postgresql.org/pgdocs/postgres/kernel-resources.html regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
