ACH STATEMENT EXECUTE PROCEDURE _ams_cluster.log_truncate('2')
Disabled user triggers:
_ams_cluster_denyaccess BEFORE INSERT OR DELETE OR UPDATE ON
ams.alert_attribute FOR EACH ROW EXECUTE PROCEDURE
_ams_cluster.denyaccess('_ams_cluster')
_ams_cluster_truncatedeny BEFO
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 mixture of DML, primarily inserts and update
abase WHERE datname = 'ams'"
datname | pg_encoding_to_char
-+-
ams | UTF8
(1 row)
r...@ams-repl7.sjc.netmgmt:~#
Tom :-)
On Tuesday, March 26, 2019, 10:14:59 AM EDT, Tom Lane
wrote:
"Brad Nicholson" writes:
> Thomas
Normally, when data corruption occurs, it appears very quickly
with a Slony-I COPY failure. It seems there may not be time to write a checksum.
Tom :-)
On Tuesday, March 26, 2019, 4:25:33 AM EDT, Laurenz Albe
wrote:
Thomas Tignor wrote:
> We are experiencing intermittent DB
Hi Brad,Thanks for writing. As I mentioned to Vijay, the "source" is a JVM
using the postgres v42.0.0 JDBC driver. I do not believe we have any explicit
encoding set, and so I expect the client encoding is SQL_ASCII. The DB is most
definitely UTF8. Our log shows no issue with the input data we'v
t catches on COPY in.
Tom :-)
Regards,
Vijay
On Tue, Mar 26, 2019 at 12:17 AM Thomas Tignor wrote:
>
> Hoping someone may be able to offer some guidance on this recurring problem.
> I am providing this "problem report" to the general list as I understand the
> bugs list requires
Hoping someone may be able to offer some guidance on this recurring problem. I
am providing this "problem report" to the general list as I understand the bugs
list requires a set of reproduction steps we do not yet have. Please advise if
I have the process wrong. I have tried to provide all know
