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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: srinivasulu <srinivasulu(at)accuracy(dot)com(dot)sg>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #16227: Loss database tables automatically in a couple of days
Date: 2020-01-27 03:16:05
Message-ID: 20200127031605.GC4913@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Christian Schwaderer 2020-01-27 05:39:54 Re: BUG #16223: Performance regression between 11.6 and 12.1 in an SQL query with a recursive CTE based on function
Previous Message Johann du Toit 2020-01-27 00:57:39 Re: BUG #16233: Yet another "logical replication worker" was terminated by signal 11: Segmentation fault