Re: dynamic shared memory: wherein I am punished for good intentions - Mailing list pgsql-hackers

From Josh Berkus
Subject Re: dynamic shared memory: wherein I am punished for good intentions
Date
Msg-id 52571899.2020202@agliodbs.com
Whole thread Raw
In response to dynamic shared memory: wherein I am punished for good intentions  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: dynamic shared memory: wherein I am punished for good intentions  (Robert Haas <robertmhaas@gmail.com>)
List 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



pgsql-hackers by date:

Previous
From: Daniel Farina
Date:
Subject: Re: pg_stat_statements: calls under-estimation propagation
Next
From: Alvaro Herrera
Date:
Subject: Re: Re: Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls