Re: [COMMITTERS] pgsql: Introduce dynamic shared memory areas.
От | Robert Haas |
---|---|
Тема | Re: [COMMITTERS] pgsql: Introduce dynamic shared memory areas. |
Дата | |
Msg-id | CA+TgmoaRjEUtnnAEf_jczULAQ4WSi_4+J6RRq5vrdMfaZd_NYw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql: Introduce dynamic shared memory areas. (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: [COMMITTERS] pgsql: Introduce dynamic shared memory areas.
|
Список | pgsql-hackers |
On Mon, Dec 5, 2016 at 7:18 AM, Michael Paquier <michael.paquier@gmail.com> wrote: > On Fri, Dec 2, 2016 at 9:36 AM, Robert Haas <rhaas@postgresql.org> wrote: >> Introduce dynamic shared memory areas. >> >> Programmers discovered decades ago that it was useful to have a simple >> interface for allocating and freeing memory, which is why malloc() and >> free() were invented. Unfortunately, those handy tools don't work >> with dynamic shared memory segments because those are specific to >> PostgreSQL and are not necessarily mapped at the same address in every >> cooperating process. So invent our own allocator instead. This makes >> it possible for processes cooperating as part of parallel query >> execution to allocate and free chunks of memory without having to >> reserve them prior to the start of execution. It could also be used >> for longer lived objects; for example, we could consider storing data >> for pg_stat_statements or the stats collector in shared memory using >> these interfaces, rather than writing them to files. Basically, >> anything that needs shared memory but can't predict in advance how >> much it's going to need might find this useful. >> >> Thomas Munro and Robert Haas. The original code (of mine) on which >> Thomas based his work was actually designed to be a new backend-local >> memory allocator for PostgreSQL, but that hasn't gone anywhere - or >> not yet, anyway. Thomas took that work and performed major >> refactoring and extensive modifications to make it work with dynamic >> shared memory, including the addition of appropriate locking. > > This commit is generating a warning when compiling on my Win7 dev box: > "C:\Users\ioltas\git\postgres\pgsql.sln" (default target) (1) -> > "C:\Users\ioltas\git\postgres\postgres.vcxproj" (default target) (2) -> > (ClCompile target) -> > src/backend/utils/mmgr/dsa.c(1921): warning C4334: '<<' : result of 32-bit sh > ift implicitly converted to 64 bits (was 64-bit shift intended?) [C:\Users\iolt > as\git\postgres\postgres.vcxproj] > > 1 Warning(s) > 0 Error(s) Hmm, I'm not sure I understand that warning. I think the complaint is about this line of code: Size threshold = 1 << (bin - 1); "bin" is declared as "Size", and threshold is also declared as "Size", so what's the problem? Is it unhappy that the "1" being shifted isn't declared as 1L? Is this a 32-bit system or a 64-bit system? Or maybe (Size) 1 << (bin - 1) would be safer? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: