Re: Dynamic shared memory areas - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Dynamic shared memory areas
Date
Msg-id CAEepm=024p-MeAsDmG=R3+tR4EGhuGJs_+rjFKF0eRoSTmMJnA@mail.gmail.com
Whole thread Raw
In response to Re: Dynamic shared memory areas  (Dilip Kumar <dilipbalaut@gmail.com>)
Responses Re: Dynamic shared memory areas
List pgsql-hackers
On Wed, Oct 5, 2016 at 10:04 PM, Dilip Kumar <dilipbalaut@gmail.com> wrote:
> On Wed, Oct 5, 2016 at 3:00 AM, Thomas Munro
> <thomas.munro@enterprisedb.com> wrote:
>> Here's a new version that does that.
>
> While testing this patch I found some issue,
>
> + total_size = DSA_INITIAL_SEGMENT_SIZE;
> + total_pages = total_size / FPM_PAGE_SIZE;
> + metadata_bytes =
> + MAXALIGN(sizeof(dsa_area_control)) +
> + MAXALIGN(sizeof(FreePageManager)) +
> + total_pages * sizeof(dsa_pointer);
> + /* Add padding up to next page boundary. */
> + if (metadata_bytes % FPM_PAGE_SIZE != 0)
> + metadata_bytes += FPM_PAGE_SIZE - (metadata_bytes % FPM_PAGE_SIZE);
> + usable_pages =
> + (total_size - metadata_bytes) / FPM_PAGE_SIZE;
>
> + segment = dsm_create(total_size, 0);
> + dsm_pin_segment(segment);
>
> Actually problem is that size of dsa_area_control is bigger than
> DSA_INITIAL_SEGMENT_SIZE.
> but we are allocating segment of DSA_INITIAL_SEGMENT_SIZE size.
>
> (gdb) p sizeof(dsa_area_control)
> $8 = 67111000
> (gdb) p DSA_INITIAL_SEGMENT_SIZE
> $9 = 1048576
>
> In dsa-v1 problem was not exist because  DSA_MAX_SEGMENTS was 1024,
> but in dsa-v2 I think it's calculated wrongly.
>
> (gdb) p DSA_MAX_SEGMENTS
> $10 = 16777216

Oops, right, thanks.  A last minute change to that macro definition
that I stupidly tested only in USE_SMALL_DSA_POINTER mode.  Here is a
fix for that, capping DSA_MAX_SEGMENTS as before.

--
Thomas Munro
http://www.enterprisedb.com

Attachment

pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: Stopping logical replication protocol
Next
From: John Gorman
Date:
Subject: Re: PATCH: two slab-like memory allocators