Re: BUG #16227: Loss database tables automatically in a couple ofdays

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: BUG #16227: Loss database tables automatically in a couple ofdays
Дата
Msg-id 20200127031605.GC4913@paquier.xyz
обсуждение исходный текст
Ответ на Re: BUG #16227: Loss database tables automatically in a couple ofdays  (Daniel Gustafsson <daniel@yesql.se>)
Список pgsql-bugs
On Fri, Jan 24, 2020 at 02:04:57PM +0100, Daniel Gustafsson wrote:
> I don't think this log dump qualifies as providing details, this is a volunteer
> driven effort where people spend their own time.  Have you gone over them to
> see if there is anything you suspect?  Looking at a single one of these, there
> are numerous DROP TABLE statements in it, and we have no way of knowing if
> thats expected or not.

Yeah.  What I can see from those logs is a bunch of logs mentioning
DDL queries doing what you are complaining about.  What you should try
to understand is from where those come from.  This comes with an effort
from your side, where you need to audit your queries, and put in place
drastic connection policies to your database.  One thing that you
should try to do first is enable log_connections and
log_disconnections.  A second is to track down the process which may
be doing that.  And that's not an issue with Postgres, that's an issue
with your server.  Postgres here simply does what it is told to.
--
Michael

Вложения

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Johann du Toit
Дата:
Сообщение: Re: BUG #16233: Yet another "logical replication worker" wasterminated by signal 11: Segmentation fault
Следующее
От: Christian Schwaderer
Дата:
Сообщение: Re: BUG #16223: Performance regression between 11.6 and 12.1 in anSQL query with a recursive CTE based on function