Re: BUG #14936: Huge backend memory usage during schema dump of database with many views
В списке pgsql-bugs по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: BUG #14936: Huge backend memory usage during schema dump of database with many views |
| Дата | |
| Msg-id | 29532.1511966886@sss.pgh.pa.us обсуждение |
| Ответ на | BUG #14936: Huge backend memory usage during schema dump of databasewith many views (maxim.boguk@gmail.com) |
| Список | pgsql-bugs |
maxim.boguk@gmail.com writes:
> I got off-list report of the following issue:
> server used all memory and crash with OOM during pg_dump of the database
> with many schemes and views.
> After removing all extra stuff problem can be show with simple run the
> following query on the database:
> select (CASE WHEN pg_has_role(c.relowner, 'USAGE'::text) THEN
> pg_get_viewdef(c.oid) ELSE NULL::text END) as view_src from pg_class c where
> (c.relkind = 'v'::"char");
Hm. It's certainly no surprise if pg_get_viewdef eats memory, but why
wouldn't it get reclaimed at the end of each tuple cycle?
Also: I don't think the above query is very representative of what
pg_dump actually does; AFAIR it pulls view definitions one at a time,
not all at once.
That leads me to guess that what's going on is relcache bloat, since
relcache entries would persist across queries. There's no mechanism
for limiting the number of entries in that cache.
regards, tom lane
В списке pgsql-bugs по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера