Re: BUG #16227: Loss database tables automatically in a couple ofdays - Mailing list pgsql-bugs

From Michael Paquier
Subject Re: BUG #16227: Loss database tables automatically in a couple ofdays
Date
Msg-id 20200127031605.GC4913@paquier.xyz
Whole thread Raw
In response to Re: BUG #16227: Loss database tables automatically in a couple ofdays  (Daniel Gustafsson <daniel@yesql.se>)
List 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

Attachment

pgsql-bugs by date:

Previous
From: Johann du Toit
Date:
Subject: Re: BUG #16233: Yet another "logical replication worker" wasterminated by signal 11: Segmentation fault
Next
From: Christian Schwaderer
Date:
Subject: Re: BUG #16223: Performance regression between 11.6 and 12.1 in anSQL query with a recursive CTE based on function