Re: [PATCH] Refactoring of LWLock tranches
От | Robert Haas |
---|---|
Тема | Re: [PATCH] Refactoring of LWLock tranches |
Дата | |
Msg-id | CA+TgmobR=_pY6iHCYQ3sCfcgw-1QfH59wgBOtF6QQhk7k4wLCw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Refactoring of LWLock tranches (Ildus Kurbangaliev <i.kurbangaliev@postgrespro.ru>) |
Ответы |
Re: [PATCH] Refactoring of LWLock tranches
Re: [PATCH] Refactoring of LWLock tranches |
Список | pgsql-hackers |
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? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: