>> < 2021-06-15 12:33:04.537 CEST > DEBUG: resetting unlogged relations: cleanup 1 init 0 > > Are you perhaps keeping your data in an UNLOGGED table? If so, resetting > it to empty after a crash is exactly what's supposed to happen. The > entire point of UNLOGGED is that the performance benefits come at the > cost of losing the data on crash.
D'oh!
Yes, that is the case. I once used this but I was convinced that I took this back in some version. It is not in my main deployment, though. Now I have to find out (a) why I have diverging deployment and (b) how that bug came about to be.
Thanks a lot!
From: Tom Lane <tgl@sss.pgh.pa.us> Sent: Tuesday, June 15, 2021 3:39:31 PM To: Holtgrewe, Manuel Cc: pgsql-general@lists.postgresql.org Subject: [ext] Re: Losing data because of problematic configuration?
"Holtgrewe, Manuel" <manuel.holtgrewe@bih-charite.de> writes: > So it looks as if the database jumps back "half an hour" to ensure consistent data. Everything in between is lost.
Postgres does not lose committed data --- if it did, we'd consider that a fairly serious bug. (Well, there are caveats of course. But most of them have to do with operating-system crashes or power loss, neither of which are at stake here.)
Are you perhaps keeping your data in an UNLOGGED table? If so, resetting it to empty after a crash is exactly what's supposed to happen. The entire point of UNLOGGED is that the performance benefits come at the cost of losing the data on crash.
