Re: Display Pg buffer cache (WIP)
От | Mark Kirkwood |
---|---|
Тема | Re: Display Pg buffer cache (WIP) |
Дата | |
Msg-id | 422B8890.7050805@coretech.co.nz обсуждение исходный текст |
Ответ на | Re: Display Pg buffer cache (WIP) (Neil Conway <neilc@samurai.com>) |
Ответы |
Re: Display Pg buffer cache (WIP)
|
Список | pgsql-patches |
Neil Conway wrote: > Tom Lane wrote: > >> It'd be possible to dispense with the per-buffer spinlocks so long as >> you look only at the tag (and perhaps the TAG_VALID flag bit). The >> tags can't be changing while you hold the BufMappingLock. > > > That's what I had thought at first, but this comment in buf_internals.h > dissuaded me: "buf_hdr_lock must be held to examine or change the tag, > flags, usage_count, refcount, or wait_backend_id fields." The comment > already notes this isn't true if you've got the buffer pinned; it would > be worth adding another exception for holding the BufMappingLock, IMHO. > >> I'm dubious that there's any point in recording information as >> transient as the refcounts and dirtybits > > > I think it's worth recording dirty bits -- it provides an indication of > the effectiveness of the bgwriter, for example. Reference counts could > be done away with, although I doubt it would have a significant effect > on the time spent holding the lock. > > Let's suppose refcount is eliminated. I will then be examining the tag, flags and buf_id elements of the buffer. Holding the BufMappingLock prevents the tag changing, but what about the flags? In addition Tom pointed out that I am not examining the BM_TAG_VALID or BM_VALID flag bits (I am only checking if tag.blockNum equals InvalidBlockNumber). My initial thought is to handle !BM_TAG_VALID or !BM_VALID similarly to InvalidBlockNumber i.e all non buf_id fields set to NULL. Mark
В списке pgsql-patches по дате отправления: