Re: Debugging leaking memory in Postgresql 13.2/Postgis 3.1
От | Paul Ramsey |
---|---|
Тема | Re: Debugging leaking memory in Postgresql 13.2/Postgis 3.1 |
Дата | |
Msg-id | 32593FA7-5D1C-4AEF-8584-C8F630E7AE8A@cleverelephant.ca обсуждение исходный текст |
Ответ на | Re: Debugging leaking memory in Postgresql 13.2/Postgis 3.1 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Debugging leaking memory in Postgresql 13.2/Postgis 3.1
|
Список | pgsql-general |
> On Mar 31, 2021, at 11:24 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Stephan Knauss <pgsql@stephans-server.de> writes: >> Hello Tom, the output below looks similar to the OOM output you >> expected. Can you give a hint how to interpret the results? > > Looks like the answer is that wherever the leak is, it's not accounted > for by this info; none of those contexts are particularly large. > > Based on nearby threads, it occurs to me to ask whether you have JIT > enabled, and if so whether turning it off helps. There seems to be > a known leak of the code fragments generated by that in some cases. > > If that's not it, then the leak must be accumulating through plain > old malloc calls. There's not much of that in the core backend > (although if you use ispell text search dictionaries, maybe [1] is > relevant), so my suspicions would next fall on any extensions you > might be using. Would be interested in the queries being run. We have a reproduceable leak in <-> geography operator that we have been unableto track down. P > > regards, tom lane > > [1] https://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=eba939551 > >
В списке pgsql-general по дате отправления: