From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: PrivateRefCount patch has got issues |
Date: | 2014-12-21 15:03:54 |
Message-ID: | 20141221150354.GB5969@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2014-12-21 16:05:10 | Re: Add min and max execute statement time in pg_stat_statement |
Previous Message | Tatsuo Ishii | 2014-12-21 14:58:32 | Re: pgbench -f and vacuum |