Ok, I'll double check to validate that there is true duplication. If shared memory cannot be swapped, and shows up in the page cache list (which would be odd, but ok, since shared mem is not page cache it is application memory), then only those pages (the actual shared_buffers) would not be swappable, not a 'clone' of those buffers in the os page cache.
I certainly don't care if the shared memory isn't pageable, I do care if a clone of that memory is also not pageable. ________________________________________ From: Pavan Deolasee [pavan.deola...@gmail.com] Sent: Thursday, December 11, 2008 12:35 AM To: Scott Carey Cc: pgsql-bugs@postgresql.org Subject: Re: [BUGS] BUG #4575: All page cache in shared_buffers pinned (duplicated by OS, always) On Thu, Dec 11, 2008 at 5:37 AM, Scott Carey <sc...@richrelevance.com> wrote: > > > Run top, and note the largest value of the "SHR" column on all postgres > processes. Now execute the os cache eviction. Check the remaining cached > memory. > Note that it is now larger than the baseline by essentially the exact size > of the postgres shared memory. > Isn't the shared memory on Linux non-swappable, unlike Solaris where you have an option to make is swappable ? As and when shared memory pages are accessed, they are allocated and can not be swapped out. I don't know if these pages are counted as part of the OS cache, but assuming they are, I don't see any problem with the above observation. May be you can try to write a C program which creates, attaches and accesses every page of the shared memory and check if you see the same behavior. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
