Re: Summary function for pg_buffercache
От | Aleksander Alekseev |
---|---|
Тема | Re: Summary function for pg_buffercache |
Дата | |
Msg-id | CAJ7c6TOgWZSdf4=Zha9isN35rh0niprtP3Eqmm=u4-M6iYa-Zg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Summary function for pg_buffercache (Melih Mutlu <m.melihmutlu@gmail.com>) |
Ответы |
Re: Summary function for pg_buffercache
Re: Summary function for pg_buffercache |
Список | pgsql-hackers |
Hi Melih, > I would appreciate any feedback/comment on this change. Another benefit of pg_buffercache_summary() you didn't mention is that it allocates much less memory than pg_buffercache_pages() does. Here is v3 where I added this to the documentation. The patch didn't apply to the current master branch with the following error: ``` pg_buffercache_pages.c:286:19: error: no member named 'rlocator' in 'struct buftag' if (bufHdr->tag.rlocator.relNumber != InvalidOid) ~~~~~~~~~~~ ^ 1 error generated. ``` I fixed this too. Additionally, the patch was pgindent'ed and some typos were fixed. However I'm afraid you can't examine BufferDesc's without taking locks. This is explicitly stated in buf_internals.h: """ Buffer header lock (BM_LOCKED flag) must be held to EXAMINE or change TAG, state or wait_backend_pgprocno fields. """ Let's consider this code again (this is after my fix): ``` if (RelFileNumberIsValid(BufTagGetRelNumber(bufHdr))) { /* ... */ } ``` When somebody modifies relNumber concurrently (e.g. calls ClearBufferTag()) this will cause an undefined behaviour. I suggest we focus on saving the memory first and then think about the performance, if necessary. -- Best regards, Aleksander Alekseev
Вложения
В списке pgsql-hackers по дате отправления: