On Wed, Sep 18, 2019 at 4:55 PM jungle boogie <jungleboogie0@gmail.com> wrote:
> $ sysctl | ag kern.seminfo.semmni
> kern.seminfo.semmni=100
It still seems to be happening. Perhaps you need to increase semmns too?
> > Scorpionfly also seems to be having problems with its git repo breaking on
> > a regular basis. I have no idea what's up with that.
>
> That is a mystery to me as well. 9.4 stable seems to be the branch with
> the most problems:
> https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=scorpionfly&br=REL9_4_STABLE
>
>
> My cronjobs:
> 0 */6 * * * cd /home/pgbuilder/bin/REL10 && ./run_build.pl --verbose
> 0 */12 * * * cd /home/pgbuilder/bin/REL10 && ./run_branches.pl --run-all
I think you need just the run_branches.pl entry.
BTW I'm sorry for my flippant tone about sem_init() earlier, which
someone pointed out to me was not great cross-project open source.
What I really meant to say was: if you have OpenBSD developer
contacts, it would be cool if you could highlight that issue as
something that would make the PostgreSQL-on-OpenBSD experience nicer
for end users (and I suspect other multi-process software too). On
Linux and FreeBSD we now use sem_init()
(PREFERRED_SEMAPHORES=UNNAMED_POSIX) so users never need to worry
about configuring that kernel resource. On at least AIX, we still
have to use SysV, but there the default limits are high enough that
(according to our manual) no adjustment is required. Also, as I
speculated in that other thread: based on a quick peek at the
implementation, you might get better performance on very large busy
PostgreSQL clusters from our cache line padded sem_init() array than
you do with your more densely packed SysV semas (I could be totally
wrong about that, but we saw an effect like that on some other
operating system).
--
Thomas Munro
https://enterprisedb.com