On Thu, 12 Nov 2015 14:59:59 -0500 Robert Haas <robertmh...@gmail.com> wrote:
> On Wed, Nov 11, 2015 at 6:50 AM, Ildus Kurbangaliev > <i.kurbangal...@postgrespro.ru> wrote: > > Attached a new version of the patch that moves SLRU tranches and LWLocks to > > SLRU control structs. > > > > `buffer_locks` field now contains LWLocks itself, so we have some economy of > > the memory here. `pstrdup` removed in SimpleLruInit. I didn't > > change names from the previous patch yet, but I don't mind if they'll > > be changed. > > I've committed this with some modifications. I did a little bit of > renaming, and I stored a copy of the SLRU name in shared memory. > Otherwise, we're relying on the fact that a static string will be at > the same backend-private address in every process, which is a > dangerous assumption at best. Thanks! That's very inspiring. I have some questions about next steps on other tranches. First of all, I think we can have two API calls, something like: 1) LWLockRequestTranche(char *tranche_name, int locks_count) 2) LWLockGetTranche(char *tranche_name) LWLockRequestTranche reserve an item in main tranches array in shared memory, and allocates space for name, LWLockTranche and LWLocks. There is first question. It is ok if this call will be from *ShmemSize functions? We keep those requests, calculate a required size in LWLockShmemSize (by moving this call to the end) and create all these tranches in CreateLWLocks. And the second issue. We have tranches created manually by backends (xlog, now SLRU), and they located in their shared memory. I suggest for them just reserving an item in the tranches array with LWLockRequestTranche(NULL, 0). About tranches that are creating after Postgres initialization I suggest don't keep them in the shared memory, just to use a local array like in the current implementation. Their name will not be read, we can determine by id that they are not in shared memory, and show "other" in pg_stat_activity and other places. ----- Ildus Kurbangaliev Postgres Professional: http://www.postgrespro.com 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
