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 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
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.
View this message in context:
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: