Re: BUG #14948: cost overflow
От | Jan Schulz |
---|---|
Тема | Re: BUG #14948: cost overflow |
Дата | |
Msg-id | CAAc324jRUEjS4W+16G-G7pUYT7ssj0sCws0xtC1=+ooZ4ndY2w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #14948: cost overflow (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: BUG #14948: cost overflow
|
Список | pgsql-bugs |
Hello, just some update on "how" that happend. Our current hypothesis: * We have one parallel job was growing so big that postgresql consumed too much memory (we use 'work_mem = 2GB'). This job is part of a process which creates a 'm_dim_next' schema which in the end would be switched to 'm_dim'. (note that the old 'm_dim' schema is not written to during the whole process which creates m_dim_next, it gets dropped after the schema switch in the last step in that process: m_dim -> m_dim_old, m_dim_next -> m_dim, drop m_dim_old) * The OOM killer killed postgresql (please note that we have configured postgres with almost no data security) * This in turn would result "somehow" in some funny data/statistics/whatever on the table in m_dim * This in turn would result in wrong plans which in turn would result in OOM when processes run which touched the table in m_dim So our current understanding is that when we fix the memory issue in the first step we will also not anymore have problems in the other processes. We are currently looking into that. Best regards, Jan -- Jan Schulz mail: jasc@gmx.net web: http://www.katzien.de
В списке pgsql-bugs по дате отправления: