Re: [RFC, POC] Don't require a NBuffer sized PrivateRefCount array of local buffer pins - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [RFC, POC] Don't require a NBuffer sized PrivateRefCount array of local buffer pins
Date
Msg-id 20396.1397052584@sss.pgh.pa.us
Whole thread Raw
In response to Re: [RFC, POC] Don't require a NBuffer sized PrivateRefCount array of local buffer pins  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: [RFC, POC] Don't require a NBuffer sized PrivateRefCount array of local buffer pins  (Andres Freund <andres@2ndquadrant.com>)
Re: [RFC, POC] Don't require a NBuffer sized PrivateRefCount array of local buffer pins  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
Andres Freund <andres@2ndquadrant.com> writes:
> On 2014-04-09 18:13:29 +0530, Pavan Deolasee wrote:
>> An orthogonal issue I noted is that we never check for overflow in the ref
>> count itself. While I understand overflowing int32 counter will take a
>> large number of pins on the same buffer, it can still happen in the worst
>> case, no ? Or is there a theoretical limit on the number of pins on the
>> same buffer by a single backend ?

> I think we'll die much earlier, because the resource owner array keeping
> track of buffer pins will be larger than 1GB.

The number of pins is bounded, more or less, by the number of scan nodes
in your query plan.  You'll have run out of memory trying to plan the
query, assuming you live that long.

The resource managers are interesting to bring up in this context.
That mechanism didn't exist when PrivateRefCount was invented.
Is there a way we could lay off the work onto the resource managers?
(I don't see one right at the moment, but I'm under-caffeinated still.)
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [RFC, POC] Don't require a NBuffer sized PrivateRefCount array of local buffer pins
Next
From: Andres Freund
Date:
Subject: Re: [RFC, POC] Don't require a NBuffer sized PrivateRefCount array of local buffer pins