RE: Too many logs are written on Windows (LOG: could not reserveshared memory region (addr=%p) for child %p:)
От | Takahashi, Ryohei |
---|---|
Тема | RE: Too many logs are written on Windows (LOG: could not reserveshared memory region (addr=%p) for child %p:) |
Дата | |
Msg-id | EE586BE92A4AFB45B03310C2A0C0565D6D33EA05@G01JPEXMBKW03 обсуждение исходный текст |
Ответ на | RE: Too many logs are written on Windows (LOG: could not reserveshared memory region (addr=%p) for child %p:) ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>) |
Ответы |
Re: Too many logs are written on Windows (LOG: could not reserveshared memory region (addr=%p) for child %p:)
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: