Re: dynamic shared memory: wherein I am punished for good intentions

From: David Johnston <polobo(at)yahoo(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 18:07:32
Message-ID: 1381428452168-5774080.post@n5.nabble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas wrote
> Unfortunately, the buildfarm
> isn't entirely happy with this decision. On buildfarm member anole
> (HP-UX B.11.31), allocation of dynamic shared memory fails with a
> "Permission denied" error, and on smew (Debian GNU/Linux 6.0), it
> fails with "Function not implemented", which according to a forum
> post[1] I found probably indicates that /dev/shm doesn't mount a tmpfs
> on that box.
>
> What shall we do about this? I see a few options.

Is this something that rightly falls into being a distro/package specific
setting? If so then the first goal should be to ensure the maximum number
of successful basic installation scenarios - namely someone installing
PostgreSQL and connect to the running postgres database without encountering
an error.

As a default I would presume the current System V behavior is sufficient to
accomplish this goal. If package maintainers can then guarantee that
changing the default will improve the user experience they should be
supported and encouraged to do so but if they are at all unsure they should
leave the default in place.

As long as a new user is able to get a running database on their machine
if/when they run up against the low defaults of System V memory they will at
least be able to focus on that single problem as opposed to having a failed
initial install and being unsure exactly what they may have done wrong.

Thus option # 2 seems sufficient. I do think that having some kind of
shared-memory-manager utility could have value but I'd rather see that be a
standalone utility as opposed to something magical done inside the bowels of
the database. While probably harder to code and learn such a utility would
provide for a much greater UX if implemented well.

David J.

--
View this message in context: http://postgresql.1045698.n5.nabble.com/dynamic-shared-memory-wherein-I-am-punished-for-good-intentions-tp5774055p5774080.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Janes 2013-10-10 18:14:27 Re: Auto-tuning work_mem and maintenance_work_mem
Previous Message Stephen Frost 2013-10-10 17:59:37 Re: Auto-tuning work_mem and maintenance_work_mem