Re: BUG #8578: loading a 33G (compressed) pg_dump into a fresh host and db instance crashes a postgresql process
В списке pgsql-bugs по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: BUG #8578: loading a 33G (compressed) pg_dump into a fresh host and db instance crashes a postgresql process |
| Дата | |
| Msg-id | 8165.1383704424@sss.pgh.pa.us обсуждение |
| Ответ на | Re: BUG #8578: loading a 33G (compressed) pg_dump into a fresh host and db instance crashes a postgresql process (Robert Nix <robert@urban4m.com>) |
| Ответы |
Re: BUG #8578: loading a 33G (compressed) pg_dump into a fresh
host and db instance crashes a postgresql process
|
| Список | pgsql-bugs |
Robert Nix <robert@urban4m.com> writes:
> Thanks for the quick response, Tom. Sure enough. I found the OOM message in
> syslog. And thanks for the link. I'll try those suggestions. Just out of
> curiosity, will using psql -f alter the behavior, in this case, with
> respect to memory?
No, since the memory consumption was happening on the server side.
It is somewhat of interest why you're apparently getting a memory leak on
the server side, though. Maybe you were using an unsafely large work_mem
or maintenance_work_mem setting? I've also seen some reports lately
suggesting that PostGIS might cause intra-query memory leaks, which might
explain this if data_partitions.zone_municipality_demog_houston contains
any PostGIS data types.
regards, tom lane
В списке pgsql-bugs по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера