From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [COMMITTERS] pgsql: Introduce dynamic shared memory areas. |
Date: | 2016-12-05 15:09:28 |
Message-ID: | CA+TgmoaRjEUtnnAEf_jczULAQ4WSi_4+J6RRq5vrdMfaZd_NYw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
On Mon, Dec 5, 2016 at 7:18 AM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> On Fri, Dec 2, 2016 at 9:36 AM, Robert Haas <rhaas(at)postgresql(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-12-05 15:17:04 | Re: [COMMITTERS] pgsql: Introduce dynamic shared memory areas. |
Previous Message | Tom Lane | 2016-12-05 15:09:05 | Re: [COMMITTERS] pgsql: Introduce dynamic shared memory areas. |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-12-05 15:17:04 | Re: [COMMITTERS] pgsql: Introduce dynamic shared memory areas. |
Previous Message | Tom Lane | 2016-12-05 15:09:05 | Re: [COMMITTERS] pgsql: Introduce dynamic shared memory areas. |