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?
I'm going to change API calls as you suggested earlier.
How you do think the tranches registration after initialization should
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: