On Sun, Nov 18, 2012 at 10:43 PM, Jeff Davis <pg...@j-davis.com> wrote:
> On Sun, 2012-11-18 at 15:19 +0100, Andres Freund wrote: > > On Sunday, November 18, 2012 03:07:01 AM Jeff Davis wrote: > > > Process A (process that clears a VM bit for a data page): > > > 1. Acquires exclusive lock on data buffer > > > 2. Acquires exclusive lock on VM buffer > > > 3. clears VM bit > > > 4. Releases VM buffer lock > > > 5. Releases data buffer lock > > > > Well, but right this is a rather big difference. If vm pages get > > unconditionally locked all the time we will have a huge source of new > > contention as they are shared between so many heap pages. > > No, that is only for the process *clearing* the bit, and this already > happens. I am not planning on introducing any new locks, aside from the > buffer header lock when acquiring a pin. And I plan to keep those pins > for long enough that those don't matter, either. > > Regards, > Jeff Davis > > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > Sorry If I am being a bit naive, but shouldnt a simple mutex work in the case when a process wants to change the VM bit in cache? Mutex would be cheaper than locks. Atri -- Regards, Atri *l'apprenant*
