Re: [RFC, POC] Don't require a NBuffer sized PrivateRefCount array of local buffer pins
От | Tom Lane |
---|---|
Тема | Re: [RFC, POC] Don't require a NBuffer sized PrivateRefCount array of local buffer pins |
Дата | |
Msg-id | 20396.1397052584@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | 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
Re: [RFC, POC] Don't require a NBuffer sized PrivateRefCount array of local buffer pins |
Список | 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 по дате отправления: