From: | Melih Mutlu <m(dot)melihmutlu(at)gmail(dot)com> |
---|---|
To: | Zhang Mingli <zmlpostgres(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Aleksander Alekseev <aleksander(at)timescale(dot)com> |
Subject: | Re: Summary function for pg_buffercache |
Date: | 2022-09-20 12:49:39 |
Message-ID: | CAGPVpCQDeA6-2b=YAQfh_fvgF6s=xkpdGGU98Ak8=cEkqK0hBQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Zhang,
Those are two different locks.
The locks that are taken in the patch are for buffer headers. This locks
only the current buffer and makes that particular buffer's info consistent
within itself.
However, the lock mentioned in the doc is for buffer manager which would
prevent changes on any buffer if it's held.
pg_buffercache_summary (and pg_buffercache_pages) does not hold buffer
manager lock. Therefore, consistency across all buffers is not guaranteed.
For pg_buffercache_pages, self-consistent buffer information is useful
since it shows each buffer separately.
For pg_buffercache_summary, even self-consistency may not matter much since
results are aggregated and we can't see individual buffer information.
Consistency across all buffers is also not a concern since its purpose is
to give an overall idea about the state of buffers.
I see that these two different locks in the same context can be confusing.
I hope it is a bit more clear now.
Best,
Melih
>
From | Date | Subject | |
---|---|---|---|
Next Message | Zhang Mingli | 2022-09-20 12:52:13 | Re: Summary function for pg_buffercache |
Previous Message | Zhang Mingli | 2022-09-20 12:48:59 | Re: Summary function for pg_buffercache |