On 8/20/23 12:10, Rihad wrote:
On 8/20/23 20:22, Adrian Klaver wrote:
On 8/18/23 22:35, Rihad wrote:
On 8/17/23 13:01, rihad wrote:
Hi, all. After calling pg_stat_reset all statistics used by
autovacuum got zeroed, and started accumulating from scratch. Some
tables get acted upon properly,
On 8/18/23 22:35, Rihad wrote:
On 8/17/23 13:01, rihad wrote:
Hi, all. After calling pg_stat_reset all statistics used by autovacuum
got zeroed, and started accumulating from scratch. Some tables get
acted upon properly, some don't.
Self-replying: yup, it seems there's an arbitrary limit o
On 8/17/23 13:01, rihad wrote:
Hi, all. After calling pg_stat_reset all statistics used by autovacuum
got zeroed, and started accumulating from scratch. Some tables get
acted upon properly, some don't.
Self-replying: yup, it seems there's an arbitrary limit of 100K of
n_live_tup after whic
Hello.
I have searched the net in an attempt to find if others have had and
resolved this challenge, but most of the sites talk about how, when
using the psql, this error arises. In my case, the error arises only
when access PG-15 using JDBC.
JDBC connects to the database, but when trying to e
Hello,
I am doing a major version upgrade from Postgres standard version
11.15 (Debian 11.15-1.pgdg90+1) to Cybertec PGEE version 14.8_EE_1.1.5
(Ubuntu 14.8ee1.1.5-1.cybertec22.04+1). While I am waiting for the
support case to be processed, I was hoping to get advice from the
Community about how t
