Re: PrivateRefCount patch has got issues

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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


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.


Andres Freund

Andres Freund
PostgreSQL Development, 24x7 Support, Training & Services

In response to


Browse pgsql-hackers by date

  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