TOAST table size in bytes growing despite working autovacuum

_vacuum_scale_factor=0.05, toast.autovacuum_vacuum_cost_limit=1000 Best regards -- Kristjan Mustkivi

Re: TOAST table size in bytes growing despite working autovacuum

On Mon, Jun 15, 2020 at 12:17 PM Laurenz Albe wrote: > > On Mon, 2020-06-15 at 11:51 +0300, Kristjan Mustkivi wrote: > > I have a table which contains a "json" column and it gets heavily > > updated. Before introducing toast.autovacuum_vacu

Re: TOAST table size in bytes growing despite working autovacuum

On Mon, Jun 15, 2020 at 4:37 PM Laurenz Albe wrote: > > On Mon, 2020-06-15 at 13:47 +0300, Kristjan Mustkivi wrote: > > Still, pgstattuple reveals that the table size is 715MB while live > > tuple len is just 39MB and 94% of the table is vacant. I do not have > > much ex

Re: Batch update million records in prd DB

TE tbl a > SET name = '' > WHERE a.id IN (SELECT id >FROM tbl b >WHERE name IS NULL >LIMIT chunk_size); > > GET DIAGNOSTICS affect_count = ROW_COUNT; > > commit; > > PERFORM pg_slee

CREATE SUBSCRIPTION not picking up .pgpass while psql does

sword Any thoughts on how to debug much appreciated. Best regards, -- Kristjan Mustkivi Email: kristjan.mustk...@gmail.com

Re: CREATE SUBSCRIPTION not picking up .pgpass while psql does

ion does not pick the .pgpass up like psql does, - that is what I cannot figure out. Cheers! -- Kristjan Mustkivi Email: kristjan.mustk...@gmail.com

Re: CREATE SUBSCRIPTION not picking up .pgpass while psql does

On Wed, Aug 31, 2022 at 4:27 PM hubert depesz lubaczewski wrote: > > On Wed, Aug 31, 2022 at 04:26:22PM +0300, Kristjan Mustkivi wrote: > > And as said, the psql utility has no problems finding the .pgass where > > it is. If I lie to it about the pgpass location i.e by giving

Index corruption revealed after upgrade to 11.17, could date back to at least 11.12

, -- Kristjan Mustkivi Email: kristjan.mustk...@gmail.com

Re: Index corruption revealed after upgrade to 11.17, could date back to at least 11.12

wrote: > > > > On Thu, Oct 27, 2022 at 10:26 AM Allan Kamau wrote: >> >> >> >> On Thu, Oct 27, 2022 at 10:20 AM Kristjan Mustkivi >> wrote: >>> >>> Dear community, >>> >>> Right after upgrading our postgres servers from 11

Re: Index corruption revealed after upgrade to 11.17, could date back to at least 11.12

On Thu, Oct 27, 2022 at 12:18 PM Peter J. Holzer wrote: > > On 2022-10-27 10:55:31 +0300, Kristjan Mustkivi wrote: > > We use dockerized postgres. > > So that means you aren't just replacing PostgreSQL, but your complete OS > (except the kernel). What is the source of y

Re: Index corruption revealed after upgrade to 11.17, could date back to at least 11.12

ous version as the comparison based on queries showed the data to be more intact with it. By the way, index rebuild while completing successfully did not fix the indexes - the data in the tables was still missing even after the successful rebuild command. I guess the only option left is to drop a

Logical Streaming Replication stuck at specific LSN

got now stuck with status "catchup" at exactly the same place. I upgraded PGEE to version 14.9 EE 1.1.6 (Ubuntu 14.9ee1.1.6-1.cybertec22.04+1) but that also did not change the situation. With best regards, -- Kristjan Mustkivi Email: kristjan.mustk...@gmail.com

How to rename in-use logical replication publication?

─────┼─── rep_sub │ postgres │ f │ {new_rep_pub} │ off│ host=localhost port=54311 dbname=postgres (1 row) Best regards, -- Kristjan Mustkivi Email: kristjan.mustk...@gmail.com

Re: How to rename in-use logical replication publication?

On Tue, Oct 19, 2021 at 10:31 PM Kristjan Mustkivi wrote: > Postgres v11.12. Getting "ERROR: publication "new_rep_pub" does not > exist" after renaming an existing publication. And the only way to get > it working seems to start from scratch. What am I missing? Ok,