On Wed, Feb 1, 2017 at 9:47 PM, Jim Nasby <jim.na...@bluetreble.com> wrote: > Before doing that the first thing to look at would be why the limit is > currently INT_MAX / 2 instead of INT_MAX.
Generally the rationale for GUCs with limits of that sort is that there is or might be code someplace that multiplies the value by 2 and expects the result not to overflow. I expect that increasing the maximum value of shared_buffers beyond what can be stored by an integer could have a noticeable distributed performance cost for the entire system. It might be a pretty small cost, but then again maybe not; for example, BufferDesc's buf_id member would have to get wider, and probably the freeNext member, too. Andres already did unspeakable things to make a BufferDesc fit into one cache line for performance reasons, so that wouldn't be great news. Anyway, I committed the patch posted here. Or the important line out of the two, anyway. :-) -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
