From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Something fishy happening on frogmouth |
Date: | 2013-10-29 19:12:20 |
Message-ID: | 6557.1383073940@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
The last two buildfarm runs on frogmouth have failed in initdb,
like this:
creating directory d:/mingw-bf/root/HEAD/pgsql.2492/src/test/regress/./tmp_check/data ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting dynamic shared memory implementation ... windows
creating configuration files ... ok
creating template1 database in d:/mingw-bf/root/HEAD/pgsql.2492/src/test/regress/./tmp_check/data/base/1 ... FATAL: could not open shared memory segment "Global/PostgreSQL.851401618": Not enough space
child process exited with exit code 1
It shouldn't be failing like that, considering that we just finished
probing for acceptable max_connections and shared_buffers without hitting
any apparent limit. I suppose it's possible that the final shm segment
size is a bit larger than what was tested at the shared_buffer step,
but that doesn't seem very likely to be the explanation. What seems
considerably more probable is that the probe for a shared memory
implementation is screwing up the system state somehow. It may not be
unrelated that this machine was happy before commit d2aecae went in.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2013-10-29 19:18:00 | Re: Fast insertion indexes: why no developments |
Previous Message | Tom Lane | 2013-10-29 18:44:26 | Re: Fast insertion indexes: why no developments |