Re: Something fishy happening on frogmouth

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Something fishy happening on frogmouth
Date: 2013-10-29 19:47:43
Message-ID: 527010DF.2030905@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 10/29/2013 03:12 PM, Tom Lane wrote:
> 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.
>
>

I'll try a run with that reverted just to see if that's it.

This is a 32 bit compiler on a 32 bit (virtual) machine, so the change
to Size is definitely more than cosmetic here.

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Leonardo Francalanci 2013-10-29 20:44:49 Re: Fast insertion indexes: why no developments
Previous Message Simon Riggs 2013-10-29 19:18:00 Re: Fast insertion indexes: why no developments