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
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 |