From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>, Andrew Dunstan <andrew@dunslane.net>
cc: pgsql-hackers@postgreSQL.org
Subject: Something fishy happening on frogmouth
Date: Tue, 29 Oct 2013 15:12:20 -0400
Message-ID: <6557.1383073940@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers