On Tue, 15 Sep 2015 14:39:51 -0400 Robert Haas <robertmh...@gmail.com> wrote:
> On Tue, Sep 15, 2015 at 12:44 PM, Ildus Kurbangaliev > <i.kurbangal...@postgrespro.ru> wrote: > > On Mon, 14 Sep 2015 06:32:22 -0400 > > Robert Haas <robertmh...@gmail.com> wrote: > > > >> On Sun, Sep 13, 2015 at 5:05 PM, Ildus Kurbangaliev > >> <i.kurbangal...@postgrespro.ru> wrote: > >> > Yes, that is because I tried to go with current convention > >> > working with shmem in Postgres (there are one function that > >> > returns the size and others that initialize that memory). But I > >> > like your suggestion about API functions, in that case number of > >> > tranches and locks will be known during the initialization. > >> > >> I also want to leave the door open to tranches that are registered > >> after initialization. At that point, it's too late to put a > >> tranche in shared memory, but you can still use DSM. > > > > We can hold some extra space in LWLockTrancheArray, add some > > function for unregistering a tranche, and reuse free items in > > LWLockTrancheId later. > > We could, but since that would be strictly more annoying and less > flexible than what we've already got, why would we? > Yes, probably. I'm going to change API calls as you suggested earlier. How you do think the tranches registration after initialization should look like? ---- Ildus Kurbangaliev Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers