Re: Printf-like function

Thank you. On Fri, Nov 11, 2022 at 11:12 PM Tom Lane wrote: > > Igor Korot writes: > > Is there a printf-lilke function inside libpq that can be used > > to create a proper query string with the proper quoting of the > > literal? > > No. You'd be better off to transmit the literal value as a >

Re: Printf-like function

Igor Korot writes: > Is there a printf-lilke function inside libpq that can be used > to create a proper query string with the proper quoting of the > literal? No. You'd be better off to transmit the literal value as a parameter. regards, tom lane

Re: Upgrading to v12

On 11/11/22 20:59, Brad White wrote: On Fri, Nov 11, 2022, 9:57 PM Adrian Klaver > wrote: Yes. The backup is from production. V9.4 is running on 5432 on all servers. That particular restore happens to be on the dev server. 5433 is v12. 1) This does not addre

Printf-like function

Hi, ALL, Is there a printf-lilke function inside libpq that can be used to create a proper query string with the proper quoting of the literal? Or I will need to use sprintf()? Thank you.

Re: Upgrading to v12

On Fri, Nov 11, 2022, 9:57 PM Adrian Klaver wrote: > On 11/11/22 18:41, Brad White wrote: > > > From your original post, what did "Not the half dozen restored copies" > > mean? > > Over time, we've restored multiple copies for testing and reproducing > > various issues. > > > > I'm only trying t

Re: Upgrading to v12

On 11/11/22 18:41, Brad White wrote: > From your original post, what did "Not the half dozen restored copies" mean? Over time, we've restored multiple copies for testing and reproducing various issues. I'm only trying to set up replication one one of those copies. > In other words define th

Re: Upgrading to v12

Sorry. Ignore the errors. That was mistakenly copied in from elsewhere.

Re: Upgrading to v12

> From your original post, what did "Not the half dozen restored copies" mean? Over time, we've restored multiple copies for testing and reproducing various issues. I'm only trying to set up replication one one of those copies. > In other words define the restore process. Command to back up the

Re: Upgrading to v12

On 11/11/22 14:06, Brad White wrote: > Can you do a pg_dump of that database? Yes. No visible problems. No errors reported. From your original post, what did "Not the half dozen restored copies" mean? In other words define the restore process. -- Adrian Klaver adrian.kla...@aklaver.com

Re: Upgrading to v12

Brad White writes: >> Can you do a pg_dump of that database? > Yes. No visible problems. No errors reported. Well, that's quite interesting, because pg_dump ought to read all the same catalogs that pg_upgrade is failing to read. So I'm not quite sure what's going on there. Nonetheless, your pat

Re: Upgrading to v12

> Can you do a pg_dump of that database? Yes. No visible problems. No errors reported. On Fri, Nov 11, 2022 at 3:17 PM Adrian Klaver wrote: > On 11/11/22 13:11, Brad White wrote: > > I deleted all the other DBs and left only the primary. > > Still getting the same error message, ending with > >

Re: Upgrading to v12

I'm practicing on our Dev server, so I can blow this away and reload at any time. Are there any utilities to check for corruption on my Prod server in v9.4.1? All my backups are done with pg_dump.exe, so that's where this database came from in the first place. So we know that pg_dump.exe works on

Re: Upgrading to v12

On 11/11/22 13:11, Brad White wrote: I deleted all the other DBs and left only the primary. Still getting the same error message, ending with ERROR:  could not access status of transaction 22316920 DETAIL:  Could not read from file "pg_clog/0015" at offset 73728: No error. Can you do a pg_dump

Re: Upgrading to v12

Brad White writes: > I deleted all the other DBs and left only the primary. > Still getting the same error message, ending with > ERROR: could not access status of transaction 22316920 > DETAIL: Could not read from file "pg_clog/0015" at offset 73728: No error. That's a pretty clear indication

Re: Upgrading to v12

I deleted all the other DBs and left only the primary. Still getting the same error message, ending with ERROR: could not access status of transaction 22316920 DETAIL: Could not read from file "pg_clog/0015" at offset 73728: No error.

Re: Upgrading to v12

> What was the complete pg_upgrade command you used? "C:\Program Files\PostgreSQL\12\bin\pg_upgrade" -d "C:\Program Files\PostgreSQL\9.4\data" -D "C:\Program Files\PostgreSQL\12\data" -b "C:\Program Files\PostgreSQL\9.4\bin" -B "C:\Program Files\PostgreSQL\12\bin" -U postgres -p 5432 -P 5435 > >

Re: Upgrading to v12

On 11/11/22 12:43, Brad White wrote: I'm upgrading from v9.4 to v12.10 as a half step to 15. Q1: How do I tell it which database to upgrade? I only need the primary. Not the half dozen restored copies. Or do I need to detach everything I don't want copied? 1) If you are using pg_upgrade then i

Re: Setting up replication on Windows, v9.4

Cranking up the log_min_messages level might help, to see what is (or is not) reaching the server. On 11/11/22 14:35, Brad White wrote: > Or manually running the application queries? That was the odd thing. It didn't appear to be in the middle of running any queries. The database shouldn't hav

Upgrading to v12

I'm upgrading from v9.4 to v12.10 as a half step to 15. Q1: How do I tell it which database to upgrade? I only need the primary. Not the half dozen restored copies. Or do I need to detach everything I don't want copied? Q2: I get this error, and then at the end, it says "No error." Performing Co

Re: Setting up replication on Windows, v9.4

> Or manually running the application queries? That was the odd thing. It didn't appear to be in the middle of running any queries. The database shouldn't have had any effect. > Anyway, try Pg 9.6. I have Pg 12 installed, so I'll try that. I'll start a new thread on my adventures in upgrading. Th

Re: Table : Bloat grow high

On 11/11/22 11:09, Alexis Zapata wrote: Hi all, In postgresql 13.5 Upgrade to at least 13.8.  (13.9 was released yesterday.) I have a table (size 3.1 GB) and in this table occurs near to 200 updates per second, after 2 days the size table is 7 GB and bloat grow to 45% and the query operation

Re: Setting up replication on Windows, v9.4

On 11/10/22 21:24, Brad White wrote: On 11/7/2022 3:42 PM, Rob Sargent wrote: > Care to share some of the ways the app stopped working? You might get a leg up on where best to remediate. I don't recall, as that was a few months ago. We are running MS-Access as a front end with Postgres as the

Re: pg_isready mandatory parameters?

"Zwettler Markus (OIZ)" writes: > I always thought all parameters are optional? No? They're optional, but maybe there is something wrong with the default values (wherever you're getting those from). pg_isready isn't really chartered to tell you about that, but I wonder what you get from psql with

Re: pg_isready mandatory parameters?

On Fri, Nov 11, 2022 at 12:09 PM Zwettler Markus (OIZ) wrote: > > I found this in PG14 è > > bash-4.4$ ./pg_isready --version > > pg_isready (PostgreSQL) 14.2 > > bash-4.4$ ./pg_isready > > /var/run/postgresql:5432 - no attempt > > bash-4.4$ ./pg_isready -h localhost > > localhost:5432 - no attemp

Table : Bloat grow high

Hi all, In postgresql 13.5 I have a table (size 3.1 GB) and in this table occurs near to 200 updates per second, after 2 days the size table is 7 GB and bloat grow to 45% and the query operations are degraded. vacuum runs every 5 seconds over this. but the bloat growth continues, to solve th

pg_isready mandatory parameters?

I found this in PG14 ==> bash-4.4$ ./pg_isready --version pg_isready (PostgreSQL) 14.2 bash-4.4$ ./pg_isready /var/run/postgresql:5432 - no attempt bash-4.4$ ./pg_isready -h localhost localhost:5432 - no attempt bash-4.4$ ./pg_isready -h localhost -p 5432 localhost:5432 - no attempt bash-4.4$ ./p

Re: pgadmin4 versions on Ubuntu 22.04

didn't notice that. pgadmin4 was working anyway but i changed it to jammy and updated anyway. richard On Thu, 10 Nov 2022 11:31:07 -0500 Adrian Klaver wrote --- On 11/10/22 08:19, Richard Welty wrote: > and that was it. uncommented the line in > > /etc/apt/sources.list.d/pga

Re: change Log language

fernando violante writes: > I need to change the language of the log from Spanish to English, , but I > understand that this change drop tables database . Uh ... no. All you need to do is change lc_messages, eg like alter system set lc_messages to 'en_US'; and "pg_ctl reload".

change Log language

Hi, I need to change the language of the log from Spanish to English, , but I understand that this change drop tables database . Is there a mechanism to make this change without losing data? Thank you in advance Fer

Re: programmatically retrieve details of a custom Postgres type

Thank you, Pavel and Tom! It works great! On Thu, Nov 10, 2022 at 9:30 PM Tom Lane wrote: > I wrote: > > For a composite type, pg_type.typrelid links to pg_class and pg_attribute > > entries that work much like a table. > > Actually, you could reverse that: for a table, pg_type.typrelid links to

get table oid in GIN extracequery function

I want to query some custom statistics in extracequery of GIN index, how should I go to find which table this index belongs to。