Re: PrivateRefCount patch has got issues - Mailing list pgsql-hackers

From Andres Freund
Subject Re: PrivateRefCount patch has got issues
Date
Msg-id 20141221150354.GB5969@alap3.anarazel.de
Whole thread Raw
In response to PrivateRefCount patch has got issues  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: PrivateRefCount patch has got issues  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi,

On 2014-12-16 18:25:13 -0500, Tom Lane wrote:
> I just happened to look into bufmgr.c for the first time in awhile, and
> noticed the privaterefcount-is-no-longer-a-simple-array stuff.  It doesn't
> look too well thought out to me.  In particular, PinBuffer_Locked calls
> GetPrivateRefCountEntry while holding a buffer-header spinlock.  That
> seems completely unacceptable.

Argh, yes. That certainly isn't ok.

The easiest way to fix that seems to be to declare that PinBuffer_Locked
can only be used when we're guaranteed to not have pinned the
buffer. That happens to be true for all the existing users. In fact all
of them even seem to require the refcount to be zero across all
backends.  That prerequisite then allows to increase the buffer header
refcount before releasing the spinlock *and* before increasing the
private refcount.

> It's also depressing that the very common code path
> ReleaseBuffer->UnpinBuffer results in a double search of the
> array/hashtable; that should be refactored to avoid that.

Sounds like a good idea, will see how that works out to look.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: PATCH: decreasing memory needlessly consumed by array_agg
Next
From: Tom Lane
Date:
Subject: Re: PrivateRefCount patch has got issues