RE: Copy data to DSA area

From: "Ideriha, Takeshi" <ideriha(dot)takeshi(at)jp(dot)fujitsu(dot)com>
To: 'Kyotaro HORIGUCHI' <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, "thomas(dot)munro(at)enterprisedb(dot)com" <thomas(dot)munro(at)enterprisedb(dot)com>, "robertmhaas(at)gmail(dot)com" <robertmhaas(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: RE: Copy data to DSA area
Date: 2019-06-24 12:53:29
Message-ID: 4E72940DA2BF16479384A86D54D0988A7DB7C199@G01JPEXMBKW04
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

>From: Ideriha, Takeshi [mailto:ideriha(dot)takeshi(at)jp(dot)fujitsu(dot)com]
>Sent: Friday, April 26, 2019 11:50 PM
>To: 'Kyotaro HORIGUCHI' <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>;
>thomas(dot)munro(at)enterprisedb(dot)com; robertmhaas(at)gmail(dot)com
>Cc: pgsql-hackers(at)postgresql(dot)org
>Subject: RE: Copy data to DSA area
>Hi, I've updated Thomas's quick PoC.


I've rebased the patch to fit the core code rather than extension.
Regarding shared memory context (ShmContext), I added three
- CreatePermShmContext
create "permanent" context located in shared memory
- CreateTempShmContext
Create "temporary" context located in local memory,
Which has buffer to keep track of possible memory leak objects
- ChangeToPermShmContext
Change allocated objects parent to permanent context

When you allocate something, add an object in the Temp ShmContext,
and re-parent it to Perm ShmContext after it becomes not leaked.

Current method of keeping track of objects and freeing them at
rollback works well for the case where delete both the parent object
and child object, which is pointed by parent. This is because no dangling
pointer remains after rollback. If child object is freed but parent object
was already allocated in the permeant context, this object has a
dangling pointer. But if an object is pointed by already permanent object,
this means that just allocated object won't be leaked. So in such cases
we could skip temporary allocation and allocate it directory to permanent
context. At rollback case, we could just leave it in the shared memory
and could make upper layer function handle its "ghost" object in a good way.
I cannot see the solution around here clearly. Do you have any thoughts?

MemoryContextMethods are not fully supported but some methods
like stats() might be needed.

Current test case is very simple and same as previous one but
implemented as isolation test. It checks if interger can be set in
shared memory and get it by another process. Actually, current test
case doesn't cover all possible case so more cases should be added.

I'll add this coming CF.

Thomas, thank you for taking some time at PGCon
to discuss this item and shared catalog cache. It was very helpful.
I'm going to submit email about shared catcache soon.

Takeshi Ideriha

Attachment Content-Type Size
0001-Shared-memory-context-backed-by-DSA-and-its-test.patch application/octet-stream 29.4 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2019-06-24 12:55:38 Re: Plugging some testing holes
Previous Message Alvaro Herrera 2019-06-24 12:52:00 Re: fix psql \conninfo & \connect when using hostaddr