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
