On Wed, Apr 6, 2011 at 6:32 PM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
> Robert Haas <robertmhaas@gmail.com> wrote:
>> The real fix for this problem is probably to have the ability to
>> actually return memory to the shared pool, rather than having
>> everyone grab as they need it until there's no more and never give
>> back. But that's not going to happen in 9.1, so the question is
>> whether this is a sufficiently serious problem that we ought to
>> impose the proposed stopgap fix between now and whenever we do
>> that.
>
> There is a middle course between leaving the current approach of
> preallocating half the maximum size and leaving the other half up
> for grabs and the course Heikki proposes of making the maximum a
> hard limit. I submitted a patch to preallocate the maximum, so a
> request for a particular HTAB object will never get "out of shared
> memory" unless it is past its maximum:
>
> http://archives.postgresql.org/message-id/4D948066020000250003C00B@gw.wicourts.gov
>
> That would leave some extra which is factored into the calculations
> up for grabs, but each table would be guaranteed at least its
> maximum number of entries. This seems pretty safe to me, and not
> very invasive. We could always revisit in this 9.2 if that's not
> good enough.
OK, I agree. We certainly can't have a temporary demand for predicate
locks starve out heavyweight locks for the rest of the postmaster
lifetime, or visca versa. So we need to do at least that much.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company