Re: add function for creating/attaching hash table in DSM registry
| От | Rahila Syed |
|---|---|
| Тема | Re: add function for creating/attaching hash table in DSM registry |
| Дата | |
| Msg-id | CAH2L28uPtxo1z_0ZP6yjNkVdgBPB7QnTA+ydn3qWAq20W-sF-A@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: add function for creating/attaching hash table in DSM registry (Nathan Bossart <nathandbossart@gmail.com>) |
| Ответы |
Re: add function for creating/attaching hash table in DSM registry
|
| Список | pgsql-hackers |
Hi,
* Using a DSA from the registry is cumbersome. You essentially need
another batch of shared memory to keep track of the pointers and do
locking, so it might not be tremendously useful on its own. AFAICT the
easiest thing to do is to store the DSA pointers in a dshash table, which
is what I've done in the test.
I am considering whether it would be better to avoid creating another DSM segment to
track the DSA handle.
Would it make more sense to track the DSAs in a separate dshash registry similar
to DSM segments?
+ /* Attach to existing DSA. */
+ dsa = dsa_attach(state->dsah);
+ dsa_pin_mapping(dsa);
+
+ *found = true;
+ }
Should this also consider the case where dsa is already mapped,
to avoid the error on attaching to the DSA twice? IIUC,
that would require calling dsa equivalent of dsm_find_mapping().
Thank you,
track the DSA handle.
Would it make more sense to track the DSAs in a separate dshash registry similar
to DSM segments?
+ /* Attach to existing DSA. */
+ dsa = dsa_attach(state->dsah);
+ dsa_pin_mapping(dsa);
+
+ *found = true;
+ }
Should this also consider the case where dsa is already mapped,
to avoid the error on attaching to the DSA twice? IIUC,
that would require calling dsa equivalent of dsm_find_mapping().
Thank you,
Rahila Syed
В списке pgsql-hackers по дате отправления: