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 |
Thread: | |
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.
Hi.
I've rebased the patch to fit the core code rather than extension.
Regarding shared memory context (ShmContext), I added three
APIs:
- 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.
P.S
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.
Regards,
Takeshi Ideriha
Attachment | Content-Type | Size |
---|---|---|
0001-Shared-memory-context-backed-by-DSA-and-its-test.patch | application/octet-stream | 29.4 KB |
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 |