Re: Something fishy happening on frogmouth

On Wed, Oct 30, 2013 at 8:22 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Oct 30, 2013 at 1:22 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>> On Wed, Oct 30, 2013 at 12:42 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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
>>
>> In windows implementation of dynamic shared memory, Size calculation
>> for creating dynamic shared memory is assuming that requested size for
>> creation of dynamic shared memory segment is uint64, which is changed
>> by commit d2aecae, so we need to change that calculation as well.
>> Please find the attached patch to fix this problem.
>
> I find it hard to believe this is the right fix. I know we have
> similar code in win32_shmem.c, but surely if size is a 32-bit unsigned
> quantity then size >> 0 is simply 0 anyway.

Err, rather, size >> 32 is simply 0 anyway.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company