Re: getting to beta
От | Robert Haas |
---|---|
Тема | Re: getting to beta |
Дата | |
Msg-id | BANLkTimVuicyZG4j3F427BgfA2iYP8Od_Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: getting to beta ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: