>> Perhaps, but I still see no reason not to apply it. It may not help >> many people, but it won't hurt anything, either. So why not? > > More complicated, less tested code. For no practial benefit, it'll still > be slower than posix shm if there's any memmory pressure. But if you > want to apply it, go ahead, I won't cry louder than this email. > > I still think the mmap dsm implementation is a bad idea. We shouldn't > put additional effort into it. If anything we should remove it.
While you're not wrong in that use of mmap(2) here is potentially a bad idea, much of that is mitigated through the correct use of flags to mmap(2) (i.e. prevent mmap(2) pages from hooking in to the syncer). In the same breath, it would also be nice if the following were committed: > --- src/template/freebsd.orig 2014-05-26 23:54:53.854165855 +0300 > +++ src/template/freebsd 2014-05-26 23:55:12.307880900 +0300 > @@ -3,3 +3,4 @@ > case $host_cpu in > alpha*) CFLAGS="-O";; # alpha has problems with -O2 > esac > +USE_NAMED_POSIX_SEMAPHORES=1 -sc -- Sean Chittenden s...@chittenden.org -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
