Re: add function for creating/attaching hash table in DSM registry - Mailing list pgsql-hackers

From Rahila Syed
Subject Re: add function for creating/attaching hash table in DSM registry
Date
Msg-id CAH2L28uPtxo1z_0ZP6yjNkVdgBPB7QnTA+ydn3qWAq20W-sF-A@mail.gmail.com
Whole thread Raw
In response to Re: add function for creating/attaching hash table in DSM registry  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: add function for creating/attaching hash table in DSM registry
List 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,
Rahila Syed

pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Cluster.pm psql() undefined $$stderr
Next
From: Yugo Nagata
Date:
Subject: Re: Suggestion to add --continue-client-on-abort option to pgbench