Re: Something fishy happening on frogmouth
От | Robert Haas |
---|---|
Тема | Re: Something fishy happening on frogmouth |
Дата | |
Msg-id | CA+TgmoaxDrdcxivPrf5TORz0heUFGEptiNsmqZgvohz57eHz8Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Something fishy happening on frogmouth (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On Wed, Oct 30, 2013 at 8:22 AM, Robert Haas <robertmhaas@gmail.com> wrote: > On Wed, Oct 30, 2013 at 1:22 AM, Amit Kapila <amit.kapila16@gmail.com> wrote: >> On Wed, Oct 30, 2013 at 12:42 AM, Tom Lane <tgl@sss.pgh.pa.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
В списке pgsql-hackers по дате отправления: