Re: Removing oids with pg_repack

Στις 21/11/23 20:41, ο/η CG έγραψε: I have a very large PostgreSQL 9.5 database that still has very large tables with oids. I'm trying to get rid of the oids with as little downtime as possible so I can prep the database for upgrade past PostgreSQL 11. I had a wild idea to mod pg_repack to

Re: Retrieve results in PostgreSQL stored procedure allowing query parallelism

On Tue, Nov 21, 2023 at 11:31 AM Joan Pujol wrote: > If I try to do something like: > EXECUTE SELECT INTO ARRAY_AGG(t.*) INTO result_records > Would internally use cursors too and have the same restrictions? > > Producing a single row single column result and then storing it into a variable

Removing oids with pg_repack

I have a very large PostgreSQL 9.5 database that still has very large tables with oids. I'm trying to get rid of the oids with as little downtime as possible so I can prep the database for upgrade past PostgreSQL 11. I had a wild idea to mod pg_repack to write a new table without oids. I think

Re: Retrieve results in PostgreSQL stored procedure allowing query parallelism

Thanks, David. If I try to do something like: EXECUTE SELECT INTO ARRAY_AGG(t.*) INTO result_records Would internally use cursors too and have the same restrictions? Cheers, On Tue, 21 Nov 2023 at 19:22, David G. Johnston wrote: > > On Tue, Nov 21, 2023, 11:10 Joan Pujol wrote: >> >> I want

Re: Retrieve results in PostgreSQL stored procedure allowing query parallelism

On Tue, Nov 21, 2023, 11:10 Joan Pujol wrote: > I want to execute an SQL query and process its results inside a stored > procedure without preventing query parallelism. Since I don't want to > prevent query parallelism, cursors can't be used, and I would like to > avoid creating a temporal

Retrieve results in PostgreSQL stored procedure allowing query parallelism

I want to execute an SQL query and process its results inside a stored procedure without preventing query parallelism. Since I don't want to prevent query parallelism, cursors can't be used, and I would like to avoid creating a temporal table. Is this possible? If so, what is the best way to

Re: client/server versions

On 11/21/23 03:28, Dick Visser wrote: Hi I'm working with AWS RDS PG instances that have been created over time, and that by now are a mix of several major/minor versions ranging from 12 to 15. The initial configuration and management is done from an EC2 instance running Debian 11, which has

Re: client/server versions

On Tue, 21 Nov 2023 at 15:00, Thiemo Kellner wrote: > > Ok, fair enough, but it puzzles me that the effort shall be put into > making a multitude of client verions working flawlessly with a multitude > of server versions instead of holding server (and client) versions the > same. > Yes, I know,

Re: client/server versions

On Tue, Nov 21, 2023 at 8:31 AM Dick Visser wrote: > On Tue, 21 Nov 2023 at 14:07, Ron Johnson wrote: > >> On Tue, Nov 21, 2023 at 6:29 AM Dick Visser wrote: >> >>> Hi >>> >>> I'm working with AWS RDS PG instances that have been created over time, >>> and that by now are a mix of several

Re: client/server versions

> On 21 Nov 2023, at 14:31, Dick Visser wrote: > On Tue, 21 Nov 2023 at 14:07, Ron Johnson > wrote: > On Tue, Nov 21, 2023 at 6:29 AM Dick Visser > wrote: > I already found out that there are compatibility issues if I use the client

Re: client/server versions

Am 21.11.2023 um 13:18 schrieb Dick Visser: It is possible, it's just that there is no real need to at the moment, ao we have not spent that much effort on the topic. At any time there will always be newer upstream versions. Ok, fair enough, but it puzzles me that the effort shall be put

Re: client/server versions

On Tue, 21 Nov 2023 at 14:07, Ron Johnson wrote: > On Tue, Nov 21, 2023 at 6:29 AM Dick Visser wrote: > >> Hi >> >> I'm working with AWS RDS PG instances that have been created over time, >> and that by now are a mix of several major/minor versions ranging from 12 >> to 15. >> The initial

Re: client/server versions

On Tue, Nov 21, 2023 at 6:29 AM Dick Visser wrote: > Hi > > I'm working with AWS RDS PG instances that have been created over time, > and that by now are a mix of several major/minor versions ranging from 12 > to 15. > The initial configuration and management is done from an EC2 instance >

Re: pgBackRest on old installation

On 21/11/2023 11:59, Achilleas Mantzios - cloud wrote: On 11/21/23 08:36, KK CHN wrote: Thank you.  Its worked out well. But a basic doubt ? is storing the DB superuser password in .pgpass is advisable ? What other options do we have ? The .pgpass file is stored in the user's home

Re: client/server versions

On Tue, 21 Nov 2023 at 12:40, Thiemo Kellner wrote: > Hi Dick > > Out of curiosity, what is the reason there is this zoo of versions. Is > it impossible to align them to one It is possible, it's just that there is no real need to at the moment, ao we have not spent that much effort on the

Re: pgBackRest on old installation

On 11/21/23 08:36, KK CHN wrote: Thank you.  Its worked out well. But a basic doubt ? is storing the DB superuser password in .pgpass is advisable ? What other options do we have ? #su postgres bash-4.2$ cd bash-4.2$ cat .pgpass *:*:*:postgres:your_password bash-4.2$ root has access to any

Re: client/server versions

Hi Dick Out of curiosity, what is the reason there is this zoo of versions. Is it impossible to align them to one version? Cheers Thiemo

client/server versions

Hi I'm working with AWS RDS PG instances that have been created over time, and that by now are a mix of several major/minor versions ranging from 12 to 15. The initial configuration and management is done from an EC2 instance running Debian 11, which has Postrgres 13.13. I already found out that