Gavin Panella <gavinpanella@gmail.com> writes:
> With that fix applied to REL_17_5 things are working well. Limiting the
> search sounds like an improvement too.
Cool. I'll push the fix after our release freeze lifts.
> Then I thought: I'm only seeing the log from one of those instances, yet
> they're all going through the same search for free semaphore sets. That's a
> few system calls going to waste. Maybe not important in the big picture,
> but it gave me an idea to left shift nextSemaKey in PGReserveSemaphores,
> i.e. `nextSemaKey = statbuf.st_ino << 4`, to give each pg_ctl process a few
> guaranteed uncontested keys (at least, uncontested between themselves). In
> a small test this eliminated contention for semaphore sets due to
> concurrency. It is more of an optimisation though, rather than a bug fix.
Meh ... if we thought this was worth worrying about, I'd be more
inclined to run the st_ino through a hash function to spread out the
possible values a little more. But I think in nearly all scenarios
it'd be a waste of effort. If collisions were probable we'd have
found this issue years ago.
regards, tom lane
