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.GB2860387@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