Re: [PATCH] Refactoring of LWLock tranches
От | Ildus Kurbangaliev |
---|---|
Тема | Re: [PATCH] Refactoring of LWLock tranches |
Дата | |
Msg-id | 20150922121610.2606746a@iw обсуждение исходный текст |
Ответ на | Re: [PATCH] Refactoring of LWLock tranches (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [PATCH] Refactoring of LWLock tranches
|
Список | pgsql-hackers |
On Tue, 15 Sep 2015 14:39:51 -0400 Robert Haas <robertmhaas@gmail.com> wrote: > On Tue, Sep 15, 2015 at 12:44 PM, Ildus Kurbangaliev > <i.kurbangaliev@postgrespro.ru> wrote: > > On Mon, 14 Sep 2015 06:32:22 -0400 > > Robert Haas <robertmhaas@gmail.com> wrote: > > > >> On Sun, Sep 13, 2015 at 5:05 PM, Ildus Kurbangaliev > >> <i.kurbangaliev@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
В списке pgsql-hackers по дате отправления: