Re: Summary function for pg_buffercache - Mailing list pgsql-hackers

From Aleksander Alekseev
Subject Re: Summary function for pg_buffercache
Date
Msg-id CAJ7c6TOgWZSdf4=Zha9isN35rh0niprtP3Eqmm=u4-M6iYa-Zg@mail.gmail.com
Whole thread Raw
In response to Re: Summary function for pg_buffercache  (Melih Mutlu <m.melihmutlu@gmail.com>)
Responses Re: Summary function for pg_buffercache
Re: Summary function for pg_buffercache
List 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

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Introduce wait_for_subscription_sync for TAP tests
Next
From: Robert Haas
Date:
Subject: Re: HOT chain validation in verify_heapam()