Re: Printf-like function

[Igor Korot]

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
> parameter.
>
> regards, tom lane

Re: Printf-like function

[Tom Lane]

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

[Adrian Klaver]

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 address from your OP:

"I only need the primary.
Not the half dozen restored copies."

And then from follow up post:

"I deleted all the other DBs and left only the primary.
Still getting the same error message, ending with"

How where the restored copies made on the original cluster?

2) For your explanation above, pg_dump from 9.4(5432) to pg_restore 
12(5433) the issue would be ...\9.4\bin\pg_dump.exe of 9.4 and 
pg_restore of said dump file to version 12. When moving up in version 
you need to use the newer version of pg_dump(...\12\bin\pg_dump.exe) to 
dump the 9.4 instance and then the version 12 pg_restore to the 12 
instance. Both programs are backwards compatible, not forwards compatible.


--
Adrian Klaver
adrian.kla...@aklaver.com

Printf-like function

[Igor Korot]

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

[Brad White]

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 to set up replication one one of those copies.
> >
> >  > In other words define the restore process.
> >
> > Command to back up the database:
> > "C:\Program Files\PostgreSQL\9.4\bin\pg_dump.exe" --host localhost
> > --port 5432 --username "postgres" --no-password  --format custom --blobs
> > --verbose --file "DB_"%datestr%"\DB_"%datestr%.backup "DB"
> >
> > Restore:
> > $pgdir\pg_restore.exe -h localhost -p 5433 -U postgres --no-password
> > --clean --if-exists --format=custom --dbname="DB_test"
> > "C:\Temp\DB_20220922_2300\DB_20220922_2300.backup"
>
> Alright I am confused. You said you had multiple copies of the database
> on one cluster.

 yes. They've been deleted now, but we did.

The above though shows you restoring to different
> cluster(5433) then the cluster(5432) you dumped from.
>

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.

>
> Also why
>
> "C:\Program Files\PostgreSQL\9.4\bin\pg_dump.exe
>
> vs
>
> $pgdir\pg_restore.exe
> ?
>
> Is pgdir different from "C:\Program Files\PostgreSQL\9.4\bin\ ?
>

"C:\Program Files... is from the backup script. Production is always only
on one version.

$pgdir is from the restore script.
So it might be
PostgreSQL\9.4\bin
   or
PostgreSQL\12\bin
   or
PostgreSQL\15\bin

Turns out that it doesn’t work well to mix the exe from one and the port
from another.

>
>
> --
> Adrian Klaver
> adrian.kla...@aklaver.com
>
>

Re: Upgrading to v12

[Adrian Klaver]

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 the restore process.

Command to back up the database:
"C:\Program Files\PostgreSQL\9.4\bin\pg_dump.exe" --host localhost 
--port 5432 --username "postgres" --no-password  --format custom --blobs 
--verbose --file "DB_"%datestr%"\DB_"%datestr%.backup "DB"


Restore:
$pgdir\pg_restore.exe -h localhost -p 5433 -U postgres --no-password 
--clean --if-exists --format=custom --dbname="DB_test" 
"C:\Temp\DB_20220922_2300\DB_20220922_2300.backup"


Alright I am confused. You said you had multiple copies of the database 
on one cluster. The above though shows you restoring to different 
cluster(5433) then the cluster(5432) you dumped from.


Also why

"C:\Program Files\PostgreSQL\9.4\bin\pg_dump.exe

vs

$pgdir\pg_restore.exe
?

Is pgdir different from "C:\Program Files\PostgreSQL\9.4\bin\ ?


--
Adrian Klaver
adrian.kla...@aklaver.com

Re: Upgrading to v12

[Brad White]

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

Re: Upgrading to v12

[Brad White]

> 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 database:
"C:\Program Files\PostgreSQL\9.4\bin\pg_dump.exe" --host localhost --port
5432 --username "postgres" --no-password  --format custom --blobs --verbose
--file "DB_"%datestr%"\DB_"%datestr%.backup "DB"

Restore:
$pgdir\pg_restore.exe -h localhost -p 5433 -U postgres --no-password
--clean --if-exists --format=custom --dbname="DB_test"
"C:\Temp\DB_20220922_2300\DB_20220922_2300.backup"

The errors looked insignificant to me. The database comes up and appears to
be perfectly functional.

pg_restore.exe : pg_restore: while INITIALIZING:
At C:\Temp\Restore12.ps1:36 char:2
+ &$prestore -h $phost -p $pport -U postgres --no-password --clean
--if-exists -- ...
+
 

+ CategoryInfo  : NotSpecified: (pg_restore: while
INITIALIZING::String) [], RemoteException
+ FullyQualifiedErrorId : NativeCommandError

pg_restore: error:
could not execute query: ERROR:  unrecognized configuration parameter
"idle_in_transaction_session_timeout"
Command was: SET idle_in_transaction_session_timeout = 0;
(Note: This is a backup from 9, being restored to 12. I assume that

pg_restore: error:
 could not execute query: ERROR:  unrecognized configuration parameter
"row_security"
Command was: SET row_security = off;

pg_restore
: WARNING:  column "Button2" has type "unknown"
DETAIL:  Proceeding with relation creation anyway.

pg_restore: WARNING:  column "Button3" has type "unknown"
DETAIL:  Proceeding with relation creation anyway.

pg_restore
: WARNING:  column "Button4" has type "unknown"
DETAIL:  Proceeding with relation creation anyway.

pg_restore: WARNING:  column "Button5" has type "unknown"
DETAIL:  Proceeding with relation creation anyway.

pg_restore
: WARNING:  column "Button6" has type "unknown"
DETAIL:  Proceeding with relation creation anyway.

pg_restore
: WARNING:  column "Button7" has type "unknown"
DETAIL:  Proceeding with relation creation anyway.

pg_restore
: warning: errors ignored on restore: 2

On Fri, Nov 11, 2022 at 3:42 PM Brad White  wrote:

> 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 Prod at least.
>
> 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
>> >
>> > 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 of that database?
>>
>>
>> --
>> Adrian Klaver
>> adrian.kla...@aklaver.com
>>
>>

Re: Upgrading to v12

[Adrian Klaver]

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

[Tom Lane]

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 path forward is clear: use pg_dump (or better pg_dumpall)
and then load the output into a freshly initdb'd v12 installation.
It'll be a bit slower than the pg_upgrade way, but it'll work.

regards, tom lane

Re: Upgrading to v12

[Brad White]

>  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
> >
> > 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 of that database?
>
>
> --
> Adrian Klaver
> adrian.kla...@aklaver.com
>
>

Re: Upgrading to v12

[Brad White]

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 Prod at least.

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
> >
> > 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 of that database?
>
>
> --
> Adrian Klaver
> adrian.kla...@aklaver.com
>
>

Re: Upgrading to v12

[Adrian Klaver]

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 of that database?


--
Adrian Klaver
adrian.kla...@aklaver.com

Re: Upgrading to v12

[Tom Lane]

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 of data corruption.  pg_upgrade
isn't going to be able to work with a corrupted source database,
so you'll have to do something to clear that before you can get
anywhere.

There's some advice about dealing with that here:

https://wiki.postgresql.org/wiki/Corruption

but in general the news is not going to be good.

regards, tom lane

Re: Upgrading to v12

[Brad White]

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

[Brad White]

>  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

[Adrian Klaver]

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 it only works on the entire cluster 
not individual databases.


2) This is not SQLite there is no detaching of databases.

3) I you want to move a single database then you are looking at 
pg_dump/pg_restore or logical replication.




Q2: I get this error, and then at the end, it says "No error."


What was the complete pg_upgrade command you used?



Performing Consistency Checks
-
Checking cluster versions                                   ok
SQL command failed
WITH regular_heap (reloid, indtable, toastheap) AS (   SELECT c.oid, 
0::oid, 0::oid   FROM pg_catalog.pg_class c JOIN pg_catalog.pg_namespace 
n          ON c.relnamespace = n.oid   WHERE relkind IN ('r', 'm') AND   
   ((n.nspname !~ '^pg_temp_' AND       n.nspname !~ '^pg_toast_temp_' 
AND       n.nspname NOT IN ('pg_catalog', 'information_schema', 
                 'binary_upgrade', 'pg_toast') AND       c.oid >= 
16384::pg_catalog.oid) OR      (n.nspname = 'pg_catalog' AND   
relname IN ('pg_largeobject') ))),   toast_heap (reloid, indtable, 
toastheap) AS (   SELECT c.reltoastrelid, 0::oid, c.oid   FROM 
regular_heap JOIN pg_catalog.pg_class c       ON regular_heap.reloid = 
c.oid   WHERE c.reltoastrelid != 0),   all_index (reloid, indtable, 
toastheap) AS (   SELECT indexrelid, indrelid, 0::oid   FROM 
pg_catalog.pg_index   WHERE indisvalid AND indisready     AND indrelid 
IN         (SELECT reloid FROM regular_heap          UNION ALL 
  SELECT reloid FROM toast_heap)) SELECT all_rels.*, n.nspname, 
c.relname,   c.relfilenode, c.reltablespace, 
pg_catalog.pg_tablespace_location(t.oid) AS spclocation FROM (SELECT * 
FROM regular_heap       UNION ALL       SELECT * FROM toast_heap   
UNION ALL       SELECT * FROM all_index) all_rels   JOIN 
pg_catalog.pg_class c       ON all_rels.reloid = c.oid   JOIN 
pg_catalog.pg_namespace n      ON c.relnamespace = n.oid   LEFT OUTER 
JOIN pg_catalog.pg_tablespace t      ON c.reltablespace = t.oid ORDER BY 1;

ERROR:  could not access status of transaction 22316920
DETAIL:  Could not read from file "pg_clog/0015" at offset 73728: No error.


--
Adrian Klaver
adrian.kla...@aklaver.com

Re: Setting up replication on Windows, v9.4

[Ron]

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 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.

Thanks,
Brad.


On Fri, Nov 11, 2022 at 12:38 PM Ron  wrote:

   Nothing in the application error logs?  What about the Postgresql
error logs?   Or manually running the application queries?

Anyway, try Pg 9.6.  Still EOL, but /not as/ EOL.

-- 
Angular momentum makes the world go 'round.




--
Angular momentum makes the world go 'round.

Upgrading to v12

[Brad White]

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 Consistency Checks
-
Checking cluster versions   ok
SQL command failed
WITH regular_heap (reloid, indtable, toastheap) AS (   SELECT c.oid,
0::oid, 0::oid   FROM pg_catalog.pg_class c JOIN pg_catalog.pg_namespace n
 ON c.relnamespace = n.oid   WHERE relkind IN ('r', 'm') AND
((n.nspname !~ '^pg_temp_' AND   n.nspname !~ '^pg_toast_temp_' AND
  n.nspname NOT IN ('pg_catalog', 'information_schema',
'binary_upgrade', 'pg_toast') AND   c.oid >= 16384::pg_catalog.oid)
OR  (n.nspname = 'pg_catalog' AND   relname IN ('pg_largeobject')
))),   toast_heap (reloid, indtable, toastheap) AS (   SELECT
c.reltoastrelid, 0::oid, c.oid   FROM regular_heap JOIN pg_catalog.pg_class
c   ON regular_heap.reloid = c.oid   WHERE c.reltoastrelid != 0),
all_index (reloid, indtable, toastheap) AS (   SELECT indexrelid, indrelid,
0::oid   FROM pg_catalog.pg_index   WHERE indisvalid AND indisready AND
indrelid IN (SELECT reloid FROM regular_heap  UNION ALL
 SELECT reloid FROM toast_heap)) SELECT all_rels.*, n.nspname,
c.relname,   c.relfilenode, c.reltablespace,
pg_catalog.pg_tablespace_location(t.oid) AS spclocation FROM (SELECT * FROM
regular_heap   UNION ALL   SELECT * FROM toast_heap   UNION ALL
  SELECT * FROM all_index) all_rels   JOIN pg_catalog.pg_class c
ON all_rels.reloid = c.oid   JOIN pg_catalog.pg_namespace n  ON
c.relnamespace = n.oid   LEFT OUTER JOIN pg_catalog.pg_tablespace t  ON
c.reltablespace = t.oid ORDER BY 1;
ERROR:  could not access status of transaction 22316920
DETAIL:  Could not read from file "pg_clog/0015" at offset 73728: No error.

Re: Setting up replication on Windows, v9.4

[Brad White]

> 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.

Thanks,
Brad.


On Fri, Nov 11, 2022 at 12:38 PM Ron  wrote:

>Nothing in the application error logs?  What about the Postgresql error
> logs?   Or manually running the application queries?
>
> Anyway, try Pg 9.6.  Still EOL, but *not as* EOL.
>
> --
> Angular momentum makes the world go 'round.
>

Re: Table : Bloat grow high

[Ron]

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 operations are degraded. vacuum runs every 5 seconds over this. 
but the bloat growth continues, to solve the
problem quickly, we have made a replica of the table with a trigger, then 
a copy of the data and in a

transaction we rename the table, but it would not be the best solution.
Some suggestion about stop this size increase or parameter to setting up?


Manually vacuum it on a regular basis.

Think about partitioning it on PK boundaries; that way you can vacuum each 
child at the same time.


--
Angular momentum makes the world go 'round.

Re: Setting up replication on Windows, v9.4

[Ron]

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 back end.
It appeared to read and write data perfectly fine, but failed in the 
business logic on the Access side where there didn't appear to be any DB 
involvement. But switching to v14 caused it and switching away fixed it.

No obvious cause that I could see.


Nothing in the application error logs?  What about the Postgresql error 
logs?   Or manually running the application queries?


Anyway, try Pg 9.6.  Still EOL, but /not as/ EOL.

--
Angular momentum makes the world go 'round.

Re: pg_isready mandatory parameters?

[Tom Lane]

"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 the same command
line option sets.

regards, tom lane

Re: pg_isready mandatory parameters?

[Jeffrey Walton]

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 attempt
>
> bash-4.4$ ./pg_isready -h localhost -p 5432
>
> localhost:5432 - no attempt
>
> bash-4.4$ ./pg_isready -h localhost -p 5432 -d postgres
>
> localhost:5432 - no attempt
>
> bash-4.4$ ./pg_isready -h localhost -p 5432 -d postgres -U postgres
>
> localhost:5432 - accepting connections
>
> I always thought all parameters are optional? No?

Optional or ignored???

This may be more what you are looking for:
https://github.com/noloader/pg_check_conn

Jeff

Table : Bloat grow high

[Alexis Zapata]

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 the

problem quickly, we have made a replica of the table with a trigger, then a 
copy of the data and in a

transaction we rename the table, but it would not be the best solution.

Some suggestion about stop this size increase or parameter to setting up?

pg_isready mandatory parameters?

[Zwettler Markus (OIZ)]

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$ ./pg_isready -h localhost -p 5432 -d postgres
localhost:5432 - no attempt
bash-4.4$ ./pg_isready -h localhost -p 5432 -d postgres -U postgres
localhost:5432 - accepting connections


I always thought all parameters are optional? No?


Thanks,
Markus

Re: pgadmin4 versions on Ubuntu 22.04

[Richard Welty]

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/pgadmin4.list 
> 
> updated and asked for an upgrade and it worked. 
> only reason i found it was i went looking to verify which repo 
> i was using and saw the comment. 
 
Did you change 
 
https://ftp.postgresql.org/pub/pgadmin/pgadmin4/apt/focal 
 
to 
 
https://ftp.postgresql.org/pub/pgadmin/pgadmin4/apt/jammy 
 
? 
 
> 
> richard 
> 
> 
> 
>  On Thu, 10 Nov 2022 11:15:02 -0500 *Richard Welty 
> * wrote --- 
> 
> may have just found the issue: 
> 
> # deb https://ftp.postgresql.org/pub/pgadmin/pgadmin4/apt/focal 
>  pgadmin4 
> main # 
> disabled on upgrade to jammy 
> 
> will retry shortly. 
> 
> richard 
> 
> 
> 
>  On Thu, 10 Nov 2022 10:58:12 -0500 *Adrian Klaver 
>  >* 
> wrote --- 
> 
> 
> 
> 
> On 11/10/22 07:48, Richard Welty wrote: 
>  > i'm currently running pgadmin4 6.12 on a Ubuntu 22.04 desktop. 
>  > it's regularly notifying me that 6.15 is available. i 
> installed using the 
>  > apt repository method in the docs, and no upgrade is 
> available there 
>  > (or at least, that's what apt reports when i ask for one.) 
> 
> What repo? 
> 
> Have you run apt update on the repo? 
> 
> What is the command you are using to do the upgrade? 
> 
>  > 
>  > wondering when the repo might get updated, or whether i should 
>  > be concerned about it at all. 
>  > 
>  > thanks, 
>  >    richard 
>  > 
>  > 
> 
> -- 
> Adrian Klaver 
> mailto:adrian.kla...@aklaver.com  
> 
> 
> 
 
-- 
Adrian Klaver 
mailto:adrian.kla...@aklaver.com

Re: change Log language

[Tom Lane]

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".

regards, tom lane

change Log language

[fernando violante]

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

[Konstantin Izmailov]

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
> pg_class and pg_attribute entries that work much like a composite type.
>
> For both relations and composite types, there are pg_class and pg_type
> entries that (by convention only) have the same names and namespaces.
> They cross-link to each other via pg_class.reltype and pg_type.typrelid.
> The associated pg_attribute entries have attrelid matching the pg_class
> OID.  The catalog entries for the two cases are pretty nearly
> indistinguishable except for pg_class.relkind.  Again, it's only by
> convention that we consider that the pg_type entry is primary for a
> composite type but pg_class is primary for a relation.
>
> Of course, a relation has some underlying storage (for most relkinds),
> and it will likely have associated entries in other catalogs that a
> composite type won't.  But the core catalog entries are about the same.
>
> regards, tom lane
>

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。