On Thu, Jan 5, 2012 at 7:26 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Thu, Jan 5, 2012 at 2:21 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> On Thu, Jan 5, 2012 at 7:12 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>>> On Thu, Jan 5, 2012 at 11:10 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>>> Let's commit the change to 32.
>>>
>>> I would like to do that, but I think we need to at least figure out a
>>> way to provide an escape hatch for people without much shared memory.
>>> We could do that, perhaps, by using a formula like this:
>>>
>>> 1 CLOG buffer per 128MB of shared_buffers, with a minimum of 8 and a
>>> maximum of 32
>>
>> We're talking about an extra 192KB or thereabouts and Clog buffers
>> will only be the size of subtrans when we've finished.
>>
>> If you want to have a special low-memory option, then it would need to
>> include many more things than clog buffers.
>>
>> Let's just use a constant value for clog buffers until the low-memory
>> patch arrives.
>
> Tom already stated that he found that unacceptable. Unless he changes
> his opinion, we're not going to get far if you're only happy if it's
> constant and he's only happy if there's a formula.
>
> On the other hand, I think there's a decent argument that he should
> change his opinion, because 192kB of memory is not a lot. However,
> what I mostly want is something that nobody hates, so we can get it
> committed and move on.
If that was a reasonable objection it would have applied when we added
serializable support, or any other SLRU for that matter.
If memory reduction is a concern to anybody, then a separate patch to
address *all* issues is required. Blocking this patch makes no sense.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services