From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: dynamic shared memory: wherein I am punished for good intentions |
Date: | 2013-10-10 21:14:01 |
Message-ID: | 52571899.2020202@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert,
>> Doesn't #2 negate all advantages of this effort? Bringing sysv
>> management back on the table seems like a giant step backwards -- or
>> am I missing something?
>
> Not unless there's no difference between "the default" and "the only option".
Well, per our earlier discussion about "the first 15 minutes", there
actually isn't a difference.
We got rid of SHMMAX for the majority of our users for 9.3. We should
NOT revert that just so we can support older platforms -- especially
since, if anything, Kernel.org is going to cripple SysV support even
further in the future. The platforms where it does work represent the
vast majority of our users, and are only on the increase.
I can only see two reasonable alternatives:
This one:
> (3) Add a new setting that auto-probes for a type of shared memory
> that works. Try POSIX first, then System V. Maybe even fall back to
> mmap'd files if neither of those works.
Or:
(5) Default to POSIX, and allow for SysV as a compile-time option for
platforms with poor POSIX memory support.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2013-10-10 21:34:19 | Re: Re: Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls |
Previous Message | Daniel Farina | 2013-10-10 20:54:50 | Re: pg_stat_statements: calls under-estimation propagation |