Andres Freund <and...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
