Re: Upgrading PG11 to PG17 without dump/restore

On 2025-05-01 23:06, Durumdara wrote: The PG_Upgrade is not possible because of lesser space and too old debian. As a data point, pg_upgrade has an option to do an in-place upgrade which reuses the vast majority of the data files as they are on disk, rather than making a copy. It's useful

Re: Upgrading PG11 to PG17 without dump/restore

On 5/1/25 06:06, Durumdara wrote: Hello! There is a heavily used server, with older debian, and PG11. The data is more than 1,2 TB. The PG_Upgrade is not possible because of lesser space and too old debian. 1) Specify what the old and new versions of Debian are. 2) I don't understand what the

Re: Upgrading PG11 to PG17 without dump/restore

On Thu, May 1, 2025 at 9:06 AM Durumdara wrote: > Hello! > > There is a heavily used server, with older debian, and PG11. > The data is more than 1,2 TB. > The PG_Upgrade is not possible because of lesser space and too old debian. > > As we see now we have only one way to move this server. > 1.)

Upgrading PG11 to PG17 without dump/restore

Hello! There is a heavily used server, with older debian, and PG11. The data is more than 1,2 TB. The PG_Upgrade is not possible because of lesser space and too old debian. As we see now we have only one way to move this server. 1.) Installing a new server with actual debian. 2.) Installing the n

Re: Slow timestamp query after upgrading from Pg13 to Pg16

On Mon, 2025-04-07 at 20:25 +0100, Simon Windsor wrote: > We used pg_dump|pg_restore to migrate the data. > > The full explain plan is at https://explain.depesz.com/s/742M. The SQL > > explain (analyze, buffers) select count(*) from consignments where > (req_status_tstamp >= '2025-03-28 00:00'::

Re: Slow timestamp query after upgrading from Pg13 to Pg16

On Mon, 2025-04-07 at 15:48 +0100, Simon Windsor wrote: > After upgrading a Db from Pg13 (Centos) to Pg16(Ubuntu) some queries > on a simple, large table (200M rows) are very slow If you used "pg_upgrade", did you ANALYZE the database? If that is not the problem, we can't gu

Re: Slow timestamp query after upgrading from Pg13 to Pg16

On 4/7/25 12:25, Simon Windsor wrote: Hi We used pg_dump|pg_restore to migrate the data. Did you do an ANALYZE on the Postgres 16 instance after the pg_restore? The full explain plan is at https://explain.depesz.com/s/742M. The SQL explain (analyze, buffers) select count(*) from consignmen

Re: Slow timestamp query after upgrading from Pg13 to Pg16

#x27;2025-03-28 01:00'::timestamp); takes 2-3s with the old Pg13 DB, and over a minute with Pg16 After spending many hours looking at DB settings and Statistic settings I am at a loss/ Simon On 07/04/2025 15:51, Laurenz Albe wrote: On Mon, 2025-04-07 at 15:48 +0100, Simon Windsor wrote: Afte

Slow timestamp query after upgrading from Pg13 to Pg16

Hello After upgrading a Db from Pg13 (Centos) to Pg16(Ubuntu) some queries on a simple, large table (200M rows) are very slow id integer not null status char(4) not null status_tstamp timestamp <... other columns ...> If I create indexes on * status, status_tstamp * status_tstam

Re: After upgrading libpq, the same function(PQftype) call returns a different OID

On 3/20/25 00:17, Sebastien Flaesch wrote: Let's not deviate from my request: I have implemented various DB client modules using the C client APIs, for Oracle DB, SQL Server, IBM DB2, MySQL/MariaDB, SQLite and PostgreSQL. While I like PostgreSQL a lot, this is the only case where I have to d

Re: After upgrading libpq, the same function(PQftype) call returns a different OID

On Thu, Mar 20, 2025 at 2:56 PM Tom Lane wrote: > "David G. Johnston" writes: > > On Thu, Mar 20, 2025 at 11:54 AM Tom Lane wrote: > >> I think it's a mistake to suppose that pg_type_d.h is the only > >> place where there's a risk of confusion. We should be thinking > >> about this more genera

Re: After upgrading libpq, the same function(PQftype) call returns a different OID

"David G. Johnston" writes: > On Thu, Mar 20, 2025 at 11:54 AM Tom Lane wrote: >> I think it's a mistake to suppose that pg_type_d.h is the only >> place where there's a risk of confusion. We should be thinking >> about this more generally: genbki.pl is taking zero thought to >> make what it emi

Re: After upgrading libpq, the same function(PQftype) call returns a different OID

=?utf-8?Q?=C3=81lvaro?= Herrera writes: > That said, we could add a comment that makes this more obvious: > ... > This looks a tad redundant in pg_type.h itself, but makes the generated > pg_type_d.h file more obvious: I think it's a mistake to suppose that pg_type_d.h is the only place where the

Re: After upgrading libpq, the same function(PQftype) call returns a different OID

"David G. Johnston" writes: > On Thu, Mar 20, 2025 at 2:56 PM Tom Lane wrote: >> That's documented elsewhere, I believe. For the foo_d.h files, >> I think it'd be sufficient to do something like 0001 attached. > WFM. Thanks. Thanks for looking at it. >> Also, while checking out the results,

Re: After upgrading libpq, the same function(PQftype) call returns a different OID

-gene...@postgresql.org Subject: Re: After upgrading libpq, the same function(PQftype) call returns a different OID EXTERNAL: Do not click links or open attachments if you do not recognize the sender. On Thu, Mar 20, 2025 at 4:43 PM Sebastien Flaesch wrote: > OR ( I guess I start to unders

Re: After upgrading libpq, the same function(PQftype) call returns a different OID

On 3/18/25 23:41, Sebastien Flaesch wrote: You are right Adrian, I did not search properly I found the header file here: sf@toro:/opt3/dbs/pgs/17.4$ ls -l include/postgresql/server/catalog/pg_type_d.h -rw-r--r-- 1 sf sf 9672 Mar 13 17:05 include/postgresql/server/catalog/pg_type_d.h I was n

Re: After upgrading libpq, the same function(PQftype) call returns a different OID

ian Klaver ; M Tarkeshwar Rao ; pgsql-gene...@postgresql.org Subject: Re: After upgrading libpq, the same function(PQftype) call returns a different OID EXTERNAL: Do not click links or open attachments if you do not recognize the sender. On Thu, Mar 20, 2025 at 8:42 AM Sebastien Flaesch ma

Re: After upgrading libpq, the same function(PQftype) call returns a different OID

On Thu, Mar 20, 2025 at 11:54 AM Tom Lane wrote: > =?utf-8?Q?=C3=81lvaro?= Herrera writes: > > That said, we could add a comment that makes this more obvious: > > ... > > This looks a tad redundant in pg_type.h itself, but makes the generated > > pg_type_d.h file more obvious: > > I think it's a

Re: After upgrading libpq, the same function(PQftype) call returns a different OID

On 2025-Mar-20, David G. Johnston wrote: > Yes, that blank line separating LSNOID and BOOLOID blocks the comment from > applying to the items after the blank line. That is a fairly common > convention, using whitespace to break things up. Also, assigning one macro > to another is quite distinct

Re: After upgrading libpq, the same function(PQftype) call returns a different OID

On Thu, Mar 20, 2025 at 8:42 AM Sebastien Flaesch wrote: > > */** > * * Backwards compatibility for ancient random spellings of pg_type OID > macros.* > * * Don't use these names in new code.* > * */* > #define CASHOID MONEYOID > #define LSNOID PG_LSNOID > > #define BOOLOID 16 > #define BYTEAOID

Re: After upgrading libpq, the same function(PQftype) call returns a different OID

On Thu, Mar 20, 2025 at 4:43 PM Sebastien Flaesch wrote: > OR ( I guess I start to understand the code... ) it this comment only for: > #define CASHOID MONEYOID > #define LSNOID PG_LSNOID That's what Tom already replied, yes. --DD

Re: After upgrading libpq, the same function(PQftype) call returns a different OID

API doc would. Seb From: Tom Lane Sent: Thursday, March 20, 2025 3:31 PM To: Sebastien Flaesch Cc: Adrian Klaver ; M Tarkeshwar Rao ; pgsql-gene...@postgresql.org Subject: Re: After upgrading libpq, the same function(PQftype) call returns a different OID EXTERNAL: Do not

Re: After upgrading libpq, the same function(PQftype) call returns a different OID

Sebastien Flaesch writes: > Native PostgreSQL built-in SQL types should be listed in a .h header of the C > client API They are. You were already pointed to it. The fact that you don't like how that file's name is spelled is not really going to impress anyone. regards,

Re: After upgrading libpq, the same function(PQftype) call returns a different OID

On Thu, Mar 20, 2025 at 8:18 AM Sebastien Flaesch wrote: > > Let's not deviate from my request: > > I have implemented various DB client modules using the C client APIs, for > Oracle DB, SQL Server, IBM DB2, MySQL/MariaDB, SQLite and PostgreSQL. > Good for you! I don't think anybody is trying to

Re: After upgrading libpq, the same function(PQftype) call returns a different OID

ien Flaesch ; M Tarkeshwar Rao ; pgsql-gene...@postgresql.org Subject: Re: After upgrading libpq, the same function(PQftype) call returns a different OID EXTERNAL: Do not click links or open attachments if you do not recognize the sender. Adrian Klaver writes: > On 3/18/25 23:41, Sebastie

Re: After upgrading libpq, the same function(PQftype) call returns a different OID

Adrian Klaver writes: > On 3/18/25 23:41, Sebastien Flaesch wrote: >> I was not expecting this file to be in a "server" folder, when it's to >> be used for client apps. > Not surprising. As I understand it this is the code used to build the > type entries in the system catalog pg_type. More th

Re: After upgrading libpq, the same function(PQftype) call returns a different OID

erver" folder, when it's to be used for client apps. And still, I do not trust the content. Seb From: Adrian Klaver Sent: Tuesday, March 18, 2025 7:41 PM To: Sebastien Flaesch ; Tom Lane ; M Tarkeshwar Rao Cc: pgsql-gene...@postgresql.org Subject: Re:

Re: After upgrading libpq, the same function(PQftype) call returns a different OID

On 3/16/25 02:30, Sebastien Flaesch wrote: Hello, I think the column type identification with PQftype() needs some review/clarification. It's a pity that libpq does not have an API to return directly the actual type name of a column. The doc

Re: After upgrading libpq, the same function(PQftype) call returns a different OID

From: Tom Lane Sent: Saturday, March 15, 2025 8:02 PM To: M Tarkeshwar Rao Cc: pgsql-gene...@postgresql.org Subject: Re: After upgrading libpq, the same function(PQftype) call returns a different OID EXTERNAL: Do not click links or open attachments if you do not recognize the sender. M T

Re: After upgrading libpq, the same function(PQftype) call returns a different OID

M Tarkeshwar Rao writes: > We are using PostgreSQL libpq in our application. The code worked fine for > the past four years, but after upgrading the library, the function PQftype is > returning unexpected values for some columns. > Specifically, the issue occurs with a column of ty

After upgrading libpq, the same function(PQftype) call returns a different OID

Hi all, We are using PostgreSQL libpq in our application. The code worked fine for the past four years, but after upgrading the library, the function PQftype is returning unexpected values for some columns. Specifically, the issue occurs with a column of type timestamp(3) without time zone

Re: The performance issues caused by upgrading PostgreSQL to version 16.3.

On 2/16/25 23:55, 馬 騰飛 wrote: Dear PostgreSQL Community, I hope this message finds you well. I am reaching out to seek your technical assistance regarding a performance issue we encountered after upgrading our PostgreSQL version from 12.19 to 16.3. We have noticed a significant performance

Re: The performance issues caused by upgrading PostgreSQL to version 16.3.

post installing, did you run analyze verbose? -Doron On Mon, Feb 17, 2025 at 4:23 PM Greg Sabino Mullane wrote: > On Mon, Feb 17, 2025 at 2:55 AM 馬 騰飛 wrote: > >> Interestingly, when we isolate the problematic SQL statement and replace >> its parameters with actual values, it executes in just

Re: The performance issues caused by upgrading PostgreSQL to version 16.3.

On Mon, Feb 17, 2025 at 2:55 AM 馬 騰飛 wrote: > Interestingly, when we isolate the problematic SQL statement and replace > its parameters with actual values, it executes in just a few seconds in > pgAdmin. > However, when we run the same SQL query through our application using > Npgsql, it takes ov

Re: The performance issues caused by upgrading PostgreSQL to version 16.3.

On Mon, Feb 17, 2025 at 2:55 AM 馬 騰飛 wrote: > Dear PostgreSQL Community, > > I hope this message finds you well. I am reaching out to seek your > technical assistance regarding a performance issue we encountered after > upgrading our PostgreSQL version from 12.19 to 16.3. >

Re: The performance issues caused by upgrading PostgreSQL to version 16.3.

On Mon, 2025-02-17 at 07:55 +, 馬　騰飛 wrote: > I am reaching out to seek your technical assistance regarding a performance > issue we encountered after upgrading our PostgreSQL version from 12.19 to > 16.3. > We have noticed a significant performance problem with a specific SQL qu

The performance issues caused by upgrading PostgreSQL to version 16.3.

Dear PostgreSQL Community, I hope this message finds you well. I am reaching out to seek your technical assistance regarding a performance issue we encountered after upgrading our PostgreSQL version from 12.19 to 16.3. We have noticed a significant performance problem with a specific SQL query

Re: Questions on Upgrading PostgreSQL from 15.0 to 15.9 and Setting Up Streaming Replication

to use a switchover first? > You can upgrade the standby, then switchover to it. > (You could even don't switchover back, when the old primary > would be upgraded and synchonized). > > > > * After upgrading the old primary server to version 15.9, I > wan

Re: Questions on Upgrading PostgreSQL from 15.0 to 15.9 and Setting Up Streaming Replication

imary, and then upgrade the old primary > server to version 15.9. 1) Why do you want to use a switchover first? You can upgrade the standby, then switchover to it. (You could even don't switchover back, when the old primary would be upgraded and synchonized). > * Afte

Re: Questions on Upgrading PostgreSQL from 15.0 to 15.9 and Setting Up Streaming Replication

On Sun, Nov 24, 2024 at 4:58 PM Adrian Klaver wrote: > On 11/24/24 13:00, Ron Johnson wrote: > > On Sun, Nov 24, 2024 at 2:55 PM Christophe Pettus > > wrote: > > > > > On Nov 24, 2024, at 09:15, Ron Johnson > > wrote: > > >

Re: Questions on Upgrading PostgreSQL from 15.0 to 15.9 and Setting Up Streaming Replication

On 11/24/24 13:00, Ron Johnson wrote: On Sun, Nov 24, 2024 at 2:55 PM Christophe Pettus > wrote: > On Nov 24, 2024, at 09:15, Ron Johnson mailto:ronljohnso...@gmail.com>> wrote: > > Doesn't the existence of a replication slot force PG to retain WAL fi

Re: Questions on Upgrading PostgreSQL from 15.0 to 15.9 and Setting Up Streaming Replication

On Sun, Nov 24, 2024 at 2:55 PM Christophe Pettus wrote: > > On Nov 24, 2024, at 09:15, Ron Johnson wrote: > > > > Doesn't the existence of a replication slot force PG to retain WAL files > when replication is broken? > > It does. I don't recall if the OP said that they were using a persistent

Re: Questions on Upgrading PostgreSQL from 15.0 to 15.9 and Setting Up Streaming Replication

> On Nov 24, 2024, at 09:15, Ron Johnson wrote: > > Doesn't the existence of a replication slot force PG to retain WAL files when > replication is broken? It does. I don't recall if the OP said that they were using a persistent replication slot or not; it's not as common with binary replic

Re: Questions on Upgrading PostgreSQL from 15.0 to 15.9 and Setting Up Streaming Replication

Thank you, everyone, for your valuable clarifications and insights. Your guidance has been incredibly helpful in addressing my concerns and understanding the best approach to proceed. I truly appreciate the time and effort you’ve taken to assist me. On Sun, 24 Nov 2024 at 22:36, Christophe Pettus

Re: Questions on Upgrading PostgreSQL from 15.0 to 15.9 and Setting Up Streaming Replication

> On Nov 24, 2024, at 09:03, Subhash Udata wrote: > When we shut down the standby, upgrade it, and then start it back up, will > the replication automatically resume from the primary to the standby? Assuming that the standby has access to any WAL generated during the shutdown (either still i

Re: Questions on Upgrading PostgreSQL from 15.0 to 15.9 and Setting Up Streaming Replication

On Sun, Nov 24, 2024 at 12:06 PM Christophe Pettus wrote: > > On Nov 24, 2024, at 09:03, Subhash Udata wrote: > > When we shut down the standby, upgrade it, and then start it back up, > will the replication automatically resume from the primary to the standby? > > Assuming that the standby has a

Re: Questions on Upgrading PostgreSQL from 15.0 to 15.9 and Setting Up Streaming Replication

r. You can do the primary and secondary in either order, although upgrading the primary first is probably the safest route. You don't have to switch the primary / secondary roles in this case, nor rebuild the secondary server using pg_basebackup.

Re: Questions on Upgrading PostgreSQL from 15.0 to 15.9 and Setting Up Streaming Replication

Thank you for your valuable suggestion! I have a question regarding the process: When we shut down the standby, upgrade it, and then start it back up, will the replication automatically resume from the primary to the standby? Looking forward to your clarification. 2) What do you mean by resource

Re: Questions on Upgrading PostgreSQL from 15.0 to 15.9 and Setting Up Streaming Replication

On Sun, Nov 24, 2024 at 11:52 AM Subhash Udata wrote: > I understand your point and appreciate the clarification. > > I have reviewed the references and now have a better understanding of the > minor upgrade process. > > However, my concern lies in the fact that we are working with production > s

Re: Questions on Upgrading PostgreSQL from 15.0 to 15.9 and Setting Up Streaming Replication

> > > *Upgrade and Replication Compatibility*: > > > > > > * My plan is to perform a failover, promote the standby > server > > > (currently 15.0) to primary, and then upgrade the old > primary > > > server to versi

Re: Questions on Upgrading PostgreSQL from 15.0 to 15.9 and Setting Up Streaming Replication

On Sun, Nov 24, 2024 at 11:41 AM Adrian Klaver wrote: > On 11/24/24 08:36, Subhash Udata wrote: > > The reason to upgrade from 15.0 to 15.9 is this > > https://www.postgresql.org/support/security/CVE-2024-10979/ > > > > > > Here it is

Re: Questions on Upgrading PostgreSQL from 15.0 to 15.9 and Setting Up Streaming Replication

you start it back up, replication from the still-15.0 primary will catch back up to the now-patched Secondary. Fail over to the Secondary (now new-Primary), and then patch old-Primary to 15.10. > >1. > - After upgrading the old primary server to version 15.9, I want to >

Re: Questions on Upgrading PostgreSQL from 15.0 to 15.9 and Setting Up Streaming Replication

n Compatibility*: > >       * My plan is to perform a failover, promote the standby server >         (currently 15.0) to primary, and then upgrade the old primary >         server to version 15.9. >       * After upgrading the old primary server to version 15

Re: Questions on Upgrading PostgreSQL from 15.0 to 15.9 and Setting Up Streaming Replication

rrently 15.0) to primary, and then upgrade the old primary > > server to version 15.9. > > * After upgrading the old primary server to version 15.9, I want > > to configure it as a standby server and set up streaming > > replication with the new pr

Re: Questions on Upgrading PostgreSQL from 15.0 to 15.9 and Setting Up Streaming Replication

the upgrade and replication process: 1. *Upgrade and Replication Compatibility*: * My plan is to perform a failover, promote the standby server (currently 15.0) to primary, and then upgrade the old primary server to version 15.9. * After upgrading the old primary

Questions on Upgrading PostgreSQL from 15.0 to 15.9 and Setting Up Streaming Replication

. *Upgrade and Replication Compatibility*: - My plan is to perform a failover, promote the standby server (currently 15.0) to primary, and then upgrade the old primary server to version 15.9. - After upgrading the old primary server to version 15.9, I want to configure it

RE: Compatibility Issues with Npgsql and .NET Framework 3.5 after Upgrading to PostgreSQL 16.3

October 30, 2024 12:06 AM To: Daniel Gustafsson ; 馬　騰飛 Cc: pgsql-general@lists.postgresql.org Subject: Re: Compatibility Issues with Npgsql and .NET Framework 3.5 after Upgrading to PostgreSQL 16.3 CAUTION：This is an external email. Please be cautious when opening links or attachments in email.

Re: Compatibility Issues with Npgsql and .NET Framework 3.5 after Upgrading to PostgreSQL 16.3

offer any advice, but it sounds like the problems is that the server wants to use SCRAM passwords and your version of npgsql only support cleartext and md5. Changing the METHOD in pg_hba.conf to md5 could fix the immediate problem perhaps but upgrading to a version that support SCRAM seems the most a

Re: Compatibility Issues with Npgsql and .NET Framework 3.5 after Upgrading to PostgreSQL 16.3

er any advice, but it sounds like the problems is that the server wants to use SCRAM passwords and your version of npgsql only support cleartext and md5. Changing the METHOD in pg_hba.conf to md5 could fix the immediate problem perhaps but upgrading to a version that support SCRAM seems the m

RE: Compatibility Issues with Npgsql and .NET Framework 3.5 after Upgrading to PostgreSQL 16.3

-general@lists.postgresql.org Subject: Re: Compatibility Issues with Npgsql and .NET Framework 3.5 after Upgrading to PostgreSQL 16.3 CAUTION：This is an external email. Please be cautious when opening links or attachments in email. > On 25 Oct 2024, at 05:45, 馬　騰飛 wrote: > > Dear P

Re: Compatibility Issues with Npgsql and .NET Framework 3.5 after Upgrading to PostgreSQL 16.3

> On 25 Oct 2024, at 05:45, 馬　騰飛 wrote: > > Dear PostgreSQL Community, > > After upgrading PostgreSQL to version 16.3, our server encountered the error > "Only AuthenticationClearTextPassword and AuthenticationMD5Password supported > for now. Received: 10"

Compatibility Issues with Npgsql and .NET Framework 3.5 after Upgrading to PostgreSQL 16.3

Dear PostgreSQL Community, After upgrading PostgreSQL to version 16.3, our server encountered the error "Only AuthenticationClearTextPassword and AuthenticationMD5Password supported for now. Received: 10" when connecting to the database. We are currently using .NET Framework version

Re: Upgrading from v12.7 to v15.7

Hi, Cstore -https://github.com/citusdata/cstore_fdw Oracle_fdw - https://github.com/laurenz/oracle_fdw/releases/tag/ORACLE_FDW_2_6_0 On Mon, Jul 8, 2024, 19:52 Yongye Serkfem wrote: > Hello Engineers, > After upgrading from v12.7 to v15.7, I ran the following command and got > t

Upgrading from v12.7 to v15.7

Hello Engineers, After upgrading from v12.7 to v15.7, I ran the following command and got this error message. postgres_upgrade_work_area]$ /usr/pgsql-15/bin/pg_upgrade \ > --check \ --old-datadir=/data/postgres12 \ > --old-datadir=/data/postgres12 \ > --new-datadir=/data/postgres \ >

Re: Seeing new stuff in log after upgrading from 11 to 15

Thanks for the quick reply! NP, I was just being extra cautious after upgrade. From: Tom Lane Sent: Wednesday, May 15, 2024 6:50 PM To: Dmitry O Litvintsev Cc: pgsql-general@lists.postgresql.org Subject: Re: Seeing new stuff in log after upgrading from

Re: Seeing new stuff in log after upgrading from 11 to 15

Dmitry O Litvintsev writes: > After upgrade 11 -> 15 started to see these messages in hot standby log: > < 2024-05-15 17:20:24.164 CDT 151879 > LOG: restartpoint complete: wrote > 296338 buffers (28.3%); 0 WAL file(s) added, 134 removed, 0 recycled; > write=1619.469 s, sync=0.022 s, total=161

Seeing new stuff in log after upgrading from 11 to 15

Hi, After upgrade 11 -> 15 started to see these messages in hot standby log: < 2024-05-15 17:20:24.164 CDT 151879 > LOG: restartpoint complete: wrote 296338 buffers (28.3%); 0 WAL file(s) added, 134 removed, 0 recycled; write=1619.469 s, sync=0.022 s, total=1619.539 s; sync files=1492, long

RE: Performance degradation after upgrading from 9.5 to 14

På lørdag 27. april 2024 kl. 11:46:26, skrev Zahir Lalani < ZahirLalani@oliver.agency >: Same issue and took us ages to work out that is was JIT! The default is on, and setting off solves the problem. I have seen several blogs reporting the same and so wonder

RE: Performance degradation after upgrading from 9.5 to 14

-generallists.postgresql.org Subject: Re: Performance degradation after upgrading from 9.5 to 14 You don't often get email from aleksandr.ja...@privatbank.ua<mailto:aleksandr.ja...@privatbank.ua>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> CAUTION: This

Re: Performance degradation after upgrading from 9.5 to 14

On Tue, 23 Apr 2024 at 07:01, Олександр Янін wrote: > Try setting enable_memoize to off. > Our practice has shown that enabling this parameter by default often resulted > in less than optimal query plans in the cache. It would be good to see a thread opened with details on this. I understand in

Re: Performance degradation after upgrading from 9.5 to 14

Try setting enable_memoize to off. Our practice has shown that enabling this parameter by default often resulted in less than optimal query plans in the cache. ср, 17 апр. 2024 г. в 20:13, Johnathan Tiamoh : > Hello, > > > I performed an upgrade from postgresql-9.5 to postgresql-14 and the > pe

Re: Performance degradation after upgrading from 9.5 to 14

I'm not sure, does it helps you but read this: https://www.cybertec-postgresql.com/en/b-tree-index-improvements-in-postgresql-v12/ "Since upgrading with pg_upgrade does not change the data files, indexes will still be in version 3 after an upgrade" I reindexed all my database, when

Re: Performance degradation after upgrading from 9.5 to 14

how about this: jit = off ? Marcin On Wed, 17 Apr 2024 at 19:33, Johnathan Tiamoh wrote: > 1) How did you upgrade? pg_dump or pg_upgrade? > > I use pg_ugrade with kink option. > > 2) Did you run ANALYZE to collect statistics after the upgrade? > > > Yes. I ran vacuumdb-analyze in stages after

Re: Performance degradation after upgrading from 9.5 to 14

1) How did you upgrade? pg_dump or pg_upgrade? I use pg_ugrade with kink option. 2) Did you run ANALYZE to collect statistics after the upgrade? Yes. I ran vacuumdb-analyze in stages after the upgrade 3) Did you transfer the configuration, or did you just create a new cluster with the default

Re: Performance degradation after upgrading from 9.5 to 14

> On Apr 17, 2024, at 10:13, Johnathan Tiamoh wrote: > I performed an upgrade from postgresql-9.5 to postgresql-14 and the > performance has degraded drastically. > > Please, is they any advice on getting performance back ? Run: VACUUM (ANALYZE, VERBOSE); More seriously (although

Re: Performance degradation after upgrading from 9.5 to 14

On 4/17/24 19:13, Johnathan Tiamoh wrote: > Hello, > > > I performed an upgrade from postgresql-9.5 to postgresql-14 and the > performance has degraded drastically. > > Please, is they any advice on getting performance back ? > There's very little practical advice we can provide based on this

Performance degradation after upgrading from 9.5 to 14

Hello, I performed an upgrade from postgresql-9.5 to postgresql-14 and the performance has degraded drastically. Please, is they any advice on getting performance back ? King Regards Johnathan T.

Fwd: Getting error while upgrading

On Sat, Mar 9, 2024 at 12:18 PM omkar narkar wrote: > Hello Team, > > I am trying to upgrade my edb 10.5 community version to postgres 15.6 > version and while doing this i am getting error regarding OIDS are not > stable across Postgresql version (sys.callback_queue_table.user_data). > Kindly he

Getting error while upgrading

Hello Team, I am trying to upgrade my edb 10.5 community version to postgres 15.6 version and while doing this i am getting error regarding OIDS are not stable across Postgresql version (sys.callback_queue_table.user_data). Kindly help me to get the solution of this issue. Thanks and regards, Omk

Re: Upgrading

You can see this document. https://www.postgresql.org/docs/current/pgupgrade.html Yours, Wen Yi ---Original--- From: "Amn Ojee Uw"

Re: Upgrading

On 7/30/23 19:22, Amn Ojee Uw wrote: Thank you Ron and Peter for taking the time to respond to my call for help. In summery, I'd like to use PostgreSQL-15. However, since my Debian 12 already has already PostgreSQL-15 installed, did I inadvertently overwrote PostgreSQL-15 when I installed Pos

Re: Upgrading

Thank you Ron and Peter for taking the time to respond to my call for help. In summery, I'd like to use PostgreSQL-15. However, since my Debian 12 already has already PostgreSQL-15 installed, did I inadvertently overwrote PostgreSQL-15 when I installed PostgreSQL-12? If so, how do I remove Pos

Re: Upgrading

On 2023-07-30 07:53:54 -0400, Amn Ojee Uw wrote: > On my Debian 12, I installed PostgreSQL-12, Where did you install that from? AFAICS, Debian 12 comes with PostgreSQL 15. > I'd like to upgrade to the latest release of PostgreSQL. So, my > question is, what is the best way to upgrade to the next

Re: Upgrading

On 7/30/23 06:53, Amn Ojee Uw wrote: Just a quick question. On my Debian 12, I installed PostgreSQL-12, I'd like to upgrade to the latest release of PostgreSQL. So, my question is, what is the best way to upgrade to the next release of PostgreSQL? To the latest release of v12 (which is 12.15

Upgrading

Just a quick question. On my Debian 12, I installed PostgreSQL-12, I'd like to upgrade to the latest release of PostgreSQL. So, my question is, what is the best way to upgrade to the next release of PostgreSQL? Thanks in advance.

Re: Problem perhaps after upgrading to pgadmin4 7.4

On 7/13/23 06:20, Carl Erik Eriksson wrote: Query tool PGadmin on my mac If I enter a query like select count(*) from table_1I get a correct response from the server If I enter select * from table_1 I get an error message that I do not understand: Error Message:missing FROM-clause entry f

Re: Problem perhaps after upgrading to pgadmin4 7.4

> On 13/07/2023 13:20 CEST Carl Erik Eriksson wrote: > > Query tool PGadmin on my mac > > If I enter a query like select count(*) from table_1I get a correct > response from the server > If I enter select * from table_1 I get an error message that I do not > understand: > Error Message:missin

Re: Problem perhaps after upgrading to pgadmin4 7.4

Problem solved - thanks Depez! (The solution for now is to downgrade to PGadmin4 version 7.2) > On 13 Jul 2023, at 13:52, hubert depesz lubaczewski wrote: > > On Thu, Jul 13, 2023 at 01:20:03PM +0200, Carl Erik Eriksson wrote: >> If I enter a query like select count(*) from table_1I get

Re: Problem perhaps after upgrading to pgadmin4 7.4

Thanks - it seems we might be on pg 10.17-1 /Carl > On 13 Jul 2023, at 13:52, hubert depesz lubaczewski wrote: > > On Thu, Jul 13, 2023 at 01:20:03PM +0200, Carl Erik Eriksson wrote: >> If I enter a query like select count(*) from table_1I get a correct >> response from the server >> If I

Re: Problem perhaps after upgrading to pgadmin4 7.4

On Thu, Jul 13, 2023 at 01:20:03PM +0200, Carl Erik Eriksson wrote: > If I enter a query like select count(*) from table_1I get a correct > response from the server > If I enter select * from table_1 I get an error message that I do not > understand: > Error Message:missing FROM-clause entry

Problem perhaps after upgrading to pgadmin4 7.4

Query tool PGadmin on my mac If I enter a query like select count(*) from table_1I get a correct response from the server If I enter select * from table_1 I get an error message that I do not understand: Error Message:missing FROM-clause entry for table "rel" LINE 8: ...ER JOIN pg_catalog.p

Re: Re[2]: Getting error while upgrading postgres from version 12 to 13

On Tue, 21 Mar 2023 at 16:06, Geoff Winkless wrote: > On Tue, 21 Mar 2023 at 10:29, shashidhar Reddy < > shashidharreddy...@gmail.com> wrote: > >> Actually I was using the below command to check the compatibility, it >> worked without any issue with 12.6 but it is not working with 1version 2.14 >

Re: Re[2]: Getting error while upgrading postgres from version 12 to 13

On Tue, 21 Mar 2023 at 10:29, shashidhar Reddy wrote: > Actually I was using the below command to check the compatibility, it > worked without any issue with 12.6 but it is not working with 1version 2.14 > time /usr/lib/postgresql/13/bin/pg_upgrade --old-bindir > /usr/lib/postgresql/12/bin --new-

Re: Getting error while upgrading postgres from version 12 to 13

On 3/21/23 08:13, shashidhar Reddy wrote: Both shows different versions as 13 shows version 13.10 and 12 shows 12. The question asked was: "Check the value that is the PG_VERSION file in each data directory. It should be 12 in /usr/pgdata/pg_data and 13 in /usr/pgdata/pg_data2." So indicate w

Re: Getting error while upgrading postgres from version 12 to 13

Both shows different versions as 13 shows version 13.10 and 12 shows 12.14 On Tue, 21 Mar, 2023, 8:09 pm Adrian Klaver, wrote: > On 3/21/23 03:29, shashidhar Reddy wrote: > > Actually I was using the below command to check the compatibility, it > > worked without any issue with 12.6 but it is no

Re: Getting error while upgrading postgres from version 12 to 13

On 3/21/23 03:29, shashidhar Reddy wrote: Actually I was using the below command to check the compatibility, it worked without any issue with 12.6 but it is not working with 1version 2.14 time /usr/lib/postgresql/13/bin/pg_upgrade --old-bindir /usr/lib/postgresql/12/bin --new-bindir /usr/lib/pos

Re: Re[2]: Getting error while upgrading postgres from version 12 to 13

Actually I was using the below command to check the compatibility, it worked without any issue with 12.6 but it is not working with 1version 2.14 time /usr/lib/postgresql/13/bin/pg_upgrade --old-bindir /usr/lib/postgresql/12/bin --new-bindir /usr/lib/postgresql/13/bin --old-datadir /usr/pgdata/pg_d

Re[2]: Getting error while upgrading postgres from version 12 to 13

Hello, As per error it seems you have initiated source data with PG13 binaries.  Could you please connect to both source and target psql and share out of select versions(); Also share pg_upgrade complete command which you are using.  Regards, Abdul Sayeed Sent from myMail for iOS Sunda

Re: Getting error while upgrading postgres from version 12 to 13

On Sat, Mar 18, 2023 at 7:27 PM shashidhar Reddy < shashidharreddy...@gmail.com> wrote: > Can someone please help me with this? > >> >> You haven't given others enough information to help you. Present to the fullest extent possible your current environment and the commands you are running. Showi

Re: Getting error while upgrading postgres from version 12 to 13

FATAL:  could not load private key file "/etc/ssl/private/ssl-cert-snakeoil.key": key values mismatch On Sun, Mar 19, 2023 at 2:09 AM shashidhar Reddy mailto:shashidharreddy...@gmail.com>> wrote: Hello, I am in a process of upgrading postgresql fro

  1   2   3   4   >