Getting "ERROR: no unpinned buffers available" on HEAD, should I investigate?

Started by Florian Pflugabout 15 years ago2 messages
#1Florian Pflug
fgp@phlo.org

Hi

When I run my FK concurrency test suite on an unpatched HEAD, I'm getting quite a lot of "no unpinned buffers available" errors.

Increasing shared_buffers from 32MB (the default) to 64MB makes the errors go away, as does setting fsync=off.

I'm not sure how many buffers a particular backend can hold at any time. I'd have though it'd be something like one per relation and scan-in-progress, with indices counting as relations. In that case, with max_connections=100, my tests shouldn't pin more than a couple of hundred buffers at a time. That, however, amounts to about 1MB or so of pinned buffers, so it shouldn't break with shared_buffers=32MB.

I'm also confused by fsync=off making a difference. That should make writing dirty buffers slower, but would it affect the number of buffers pinned?

In short, I'm wondering whether I might have hit a bug, or if I should just increase shared_buffers and move on.

best regards,
Florian Pflug

#2Alvaro Herrera
alvherre@commandprompt.com
In reply to: Florian Pflug (#1)
Re: Getting "ERROR: no unpinned buffers available" on HEAD, should I investigate?

Excerpts from Florian Pflug's message of mar dic 14 21:51:47 -0300 2010:

Hi

When I run my FK concurrency test suite on an unpatched HEAD, I'm getting quite a lot of "no unpinned buffers available" errors.

Increasing shared_buffers from 32MB (the default) to 64MB makes the errors go away, as does setting fsync=off.

I'm not sure how many buffers a particular backend can hold at any time. I'd have though it'd be something like one per relation and scan-in-progress, with indices counting as relations. In that case, with max_connections=100, my tests shouldn't pin more than a couple of hundred buffers at a time. That, however, amounts to about 1MB or so of pinned buffers, so it shouldn't break with shared_buffers=32MB.

I'm also confused by fsync=off making a difference. That should make writing dirty buffers slower, but would it affect the number of buffers pinned?

In short, I'm wondering whether I might have hit a bug, or if I should just increase shared_buffers and move on.

I remember a report of this problem some time ago, and I wasn't able to
explain it -- my calculations said, like yours, that the maximum amount
of pinned buffers I expected shouldn't have been enough to consume the
whole pool.

It would be good to trace down to the root cause.

--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support