On 7/25/19 10:24 AM, Thomas Tignor wrote:
Hi Adrian,
Thanks for responding. Below is the schema data for the tables where we
always see corruption. You'll notice they have triggers for a postgres
extension called Slony-I which provides replication service. It's not
clear if/how that's a factor
Hi Adrian,Thanks for responding. Below is the schema data for the tables where
we always see corruption. You'll notice they have triggers for a postgres
extension called Slony-I which provides replication service. It's not clear
if/how that's a factor, though.
ams=# \d ams.alert_instance
On 7/24/19 7:38 AM, Thomas Tignor wrote:
Hello postgres community,
Writing again to see if there are insights on this issue. We have had
infrequent but recurring corruption since upgrading from postgres 9.1 to
postgres 9.5. We are presently on 9.5.16. Our DB-facing app continually
performs a
On 7/24/19 7:38 AM, Thomas Tignor wrote:
Hello postgres community,
Writing again to see if there are insights on this issue. We have had
infrequent but recurring corruption since upgrading from postgres 9.1 to
postgres 9.5. We are presently on 9.5.16. Our DB-facing app continually
performs a
Hi Laurenz. Thanks for writing. I can tell you that while the error message
usually identifies just one byte (though sometimes up to three), inspection of
the data has frequently shown several bytes impacted. It often seems that the
corruption begins at one point in the row and continues to the
Thomas Tignor wrote:
> We are experiencing intermittent DB corruption in postgres 9.5.14. We are
> trying to
> identify and eliminate all sources. We are using two independent services for
> data
> replication, Slony-I v2.2.6 and a custom service developed in-house. Both are
> based
> on COPY op