RE: PostgreSQL10.x client Vs. PostgreSQL 11.x server

Hello Team, Can anyone help us to answer below query. [Ericsson] DEEPTI SHARMA Specialist ITIL 2011 Foundation Certified BDGS, R&D Ericsson 3rd Floor, ASF Insignia - Block B Kings Canyon, Gwal Pahari, Gurgaon, Haryana 122 003, India Phone 0124-6243000 deepti.s.sha...@e

Re: PostgreSQL10.x client Vs. PostgreSQL 11.x server

Hi Deepti, By using an older client, you will be missing out on the additional features that Postgres 11 (and its corresponding client) supports. By referring to the release notes, you can identify those: https://www.postgresql.org/docs/release/11.0/ You can generally use an older client with a n

Re: PostgreSQL10.x client Vs. PostgreSQL 11.x server

On 2020-03-13 08:47:59 +, Jimmy Angelakos wrote: > By using an older client, you will be missing out on the additional > features that Postgres 11 (and its corresponding client) supports. This is not correct. You can use all the additional features which only affect the server. None of the maj

Re: Streaming replication - 11.5

So in the logs I now see this : 2020-03-13 11:03:42 GMT [10.150.20.22(45294)] [27804]: [1-1] db=[unknown],user=replicator LOG: terminating walsender process due to replication timeout So I tried increasing the wal_sender_timeout to 300s but it did not help Il giorno gio 12 mar 2020 alle ore 15:

vacuum full doubled database size

We did a "vacuum full" on a database which had been interrupted by a network outage. We found the database size doubled afterwards. Autovacuum also found a lot of orphaned tables afterwards. The ophan temp objects went away after a cluster restart while the db size remained doubled. Any idea?

pg_upgrade 9.6 to 12 without 9.6 binaries

We are running Postgres 9.6 on server A. We want to upgrade it to Postgres 12 on server B. pg_upgrade requires the old (-b) and new (-B) binary set on the same server. We don't want to install both binary sets on the same server as we had some library conflicts in the past. Is there still a wa

Re: vacuum full doubled database size

A vacuum full rebuilds the tables, so yeah if it didn’t successfully complete I would expect a lot of dead data. On Fri, Mar 13, 2020 at 07:41 Zwettler Markus (OIZ) < markus.zwett...@zuerich.ch> wrote: > We did a "vacuum full" on a database which had been interrupted by a > network outage. > > >

AW: vacuum full doubled database size

Thanks. How to get rid of it. New vacuum full? Von: Michael Loftis Gesendet: Freitag, 13. März 2020 14:48 An: Zwettler Markus (OIZ) Cc: pgsql-general Betreff: Re: vacuum full doubled database size A vacuum full rebuilds the tables, so yeah if it didn’t successfully complete I would expect a

Re: ERROR: invalid memory alloc request size 1073741824

> Could you adjust your process to log the actual temp table size > each time, ie "select count(*) from temp_table" in between the > two steps, and then note whether the failures are correlated > with unusual temp table sizes? Thanks, I'll add a count there and come back with a number when we nex

Re: pg_upgrade 9.6 to 12 without 9.6 binaries

On 3/13/20 6:47 AM, Zwettler Markus (OIZ) wrote: We are running Postgres 9.6 on server A. We want to upgrade it to Postgres 12 on server B. pg_upgrade requires the old (-b) and new (-B) binary set on the same server. We don't want to install both binary sets on the same server as we had some

Re: vacuum full doubled database size

This is why I'd VACUUM FULL in a planned manner, one or two tables at a time, and *locally* from crontab. On 3/13/20 8:41 AM, Zwettler Markus (OIZ) wrote: We did a "vacuum full" on a database which had been interrupted by a network outage. We found the database size doubled afterwards. Aut

Re: Streaming replication - 11.5

On 3/13/20 4:11 AM, Nicola Contu wrote: So in the logs I now see this : 2020-03-13 11:03:42 GMT [10.150.20.22(45294)] [27804]: [1-1] db=[unknown],user=replicator LOG:  terminating walsender process due to replication timeout Yeah that's been showing up the log snippets you have been posting.

Re: vacuum full doubled database size

On 13/03/2020 15:15, Ron wrote: This is why I'd VACUUM FULL in a planned manner, one or two tables at a time, and *locally* from crontab. That's not really viable on any remotely busy system: VACUUM FULL claims exclusive table locks, causing queries to hang (https://www.postgresql.org/docs/cu

RE: vacuum full doubled database size

>Fabio Ugo Venchiarutti wrote: >On 13/03/2020 15:15, Ron wrote: >> This is why I'd VACUUM FULL in a planned manner, one or two tables at >> a time, and *locally* from crontab. > >That's not really viable on any remotely busy system: VACUUM FULL claims >exclusive table locks, causing queries to han

Re: pg_upgrade 9.6 to 12 without 9.6 binaries

Adrian Klaver writes: > On 3/13/20 6:47 AM, Zwettler Markus (OIZ) wrote: > >> We are running Postgres 9.6 on server A. >> >> We want to upgrade it to Postgres 12 on server B. >> >> pg_upgrade requires the old (-b) and new (-B) binary set on the same server. >> >> We don't want to install both bin

Re: vacuum full doubled database size

On 3/13/20 10:32 AM, Fabio Ugo Venchiarutti wrote: On 13/03/2020 15:15, Ron wrote: This is why I'd VACUUM FULL in a planned manner, one or two tables at a time, and *locally* from crontab. That's not really viable on any remotely busy system: VACUUM FULL claims exclusive table locks, causing

Re: encrypt/decrypt between javascript and postgresql.

On 3/11/20 5:46 PM, AC Gomez wrote: I'm trying to encrypt/decrypt between javascript and postgresql. I'm using this: https://gist.github.com/vlucas/2bd40f62d20c1d49237a109d491974eb algorithm to encrypt my text, and then in PostgreSQL I use PGCRYPTO.decrypt_iv to decrypt the text. I pass in