From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Peter Geoghegan <pg(at)heroku(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: dynamic shared memory: wherein I am punished for good intentions |
Date: | 2013-10-10 19:39:31 |
Message-ID: | 20131010193931.GP2706@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> On Thu, Oct 10, 2013 at 2:36 PM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
> > On Thu, Oct 10, 2013 at 9:13 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> >> (2) Default to using System V shared memory. If people want POSIX
> >> shared memory, let them change the default.
> >
> >> After some consideration, I think my vote is for option #2.
> >
> > Wouldn't that become the call of packagers?
>
> Packagers can certainly override whatever we do, but we still need to
> make the buildfarm green again.
While I agree that making the buildfarm green is valuable, I really
wonder about a system where /dev/shm is busted.
Personally, I like Andrew's suggestion to test and set accordingly, with
the default being POSIX if it's available and a fall-back to SysV (maybe
with a warning..). Going back to the situation where our default set-up
limits us to the ridiculously small SysV value would *really* suck; even
if we don't have any users today, we're certainly going to have some
soon and I don't think they'll be happy with a 24MB (or whatever) limit.
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Browne | 2013-10-10 19:41:30 | Re: Auto-tuning work_mem and maintenance_work_mem |
Previous Message | Andrew Dunstan | 2013-10-10 19:13:56 | Re: dynamic shared memory: wherein I am punished for good intentions |