Hi Noah, Magnus and Tsunakawa-san,
Thank you for replying. > Can you adopt pgbouncer, to reduce > the frequency of starting new backend processes? That should improve your > performance, too. Actually, before I found that F-secure causes this message, I recommend my customer to use connection pooling to reduce the number of connection times. > Could you collect the information > http://postgr.es/m/20181203053506.gb2860...@rfd.leadboat.com requests? > That may help us understand your system's unusual behavior. (The issue in > that > thread is related but not identical.) Sorry. Since my customer uses PostgreSQL in production environment, I cannot deploy debug modules. > In this particular case, it seems it *was* helpful, no? That's how you found > out the customer used a broken antivirus product, which may certainly also > cause *other* issues. > > Some sort of rate limiting to reduce the volume might help, but the message > itself seems to have clearly been useful. Yes. You are right. The message itself was useful. Your idea to reduce the volume seems good. > We can change pgwin32_ReserveSharedMemoryRegion() to take an argument "int > loglevel". Then the caller first calls it with LOG, and DEBUGx afterwards. > It may also be helpful for the caller to output "LOG: tried %d times to > reserve shared memory region" when the caller ran the function twice or > more before success. That explains the possibly long time or CPU spikes > of connection establishment. It seems good idea for me. Regards, Ryohei Takahashi
