Migrating postgres client(libpq) library from 12.10 to 14(Need some information)

Hi All, We are migrating our product from postgres client library libpq 12.10 to libpq 14. This is major upgrade in the client library for us. I am quite new in this migration activity. Can you please guide me or share standard steps for this migration. Which area I should see in detail so tha

Re: Putting the O/S user for "local" "peer" authentication in the "postgres" group vs chmod'ing the "pg*.conf" files to be readable by "all"

On 11/1/22 13:20, Bryn Llewellyn wrote: david.g.johns...@gmail.com wrote: I know that I've been told off for allowing "sudo" for "postgres". I'm only experimenting on my laptop. But I want to be able to stop the server, delete the datafiles, create a

Re: Putting the O/S user for "local" "peer" authentication in the "postgres" group vs chmod'ing the "pg*.conf" files to be readable by "all"

On Tue, Nov 1, 2022 at 1:39 PM David G. Johnston wrote: > On Tue, Nov 1, 2022 at 1:20 PM Bryn Llewellyn wrote: > >> >> All this leads to an obvious question: >> >> *«* >> *Given that all of the config files have been made readable by "group" >> (in contrast to the regime for the data files), wha

Re: Putting the O/S user for "local" "peer" authentication in the "postgres" group vs chmod'ing the "pg*.conf" files to be readable by "all"

On Tue, Nov 1, 2022 at 1:20 PM Bryn Llewellyn wrote: > > About "opinionated package manager", I created my installation by > following the steps described here: > > https://wiki.postgresql.org/wiki/Apt > > Yes, apt is opinionated. And of important note here - its opinions, and the supplemental w

Re: Putting the O/S user for "local" "peer" authentication in the "postgres" group vs chmod'ing the "pg*.conf" files to be readable by "all"

> david.g.johns...@gmail.com wrote: > >> b...@yugabyte.com wrote: >> >> It would seem proper to put any user who you want to set up for "local", >> "peer" authentication into the "postgres" group > > Did you really mean to write that? > > The postgres o/s user should be able to login using pee

Re: SSL/TLS encryption without

On 2022-11-01 11:13:01 -0500, Ron wrote: > sides=> select * from pg_stat_ssl where pid = 362; > -[ RECORD 1 ]-+ > pid   | 362 > ssl   | t > version   | TLSv1.2 > cipher    | ECDHE-RSA-AES256-GCM-SHA384 > bits  | 256 > compression   | f > c

Aw: Re: Putting the O/S user for "local" "peer" authentication in the "postgres" group vs chmod'ing the "pg*.conf" files to be readable by "all"

> The client user should *never* read the PostgreSQL configuration files, so if > changing > the permissions (which you should *never* do) has an effect, you must be > doing something > very strange, like trying to start the database server with the wrong user. It smells of trying to *embed* Pos

SSL/TLS encryption without

AWS RDS Postgresql 12.11 sides=> select * from pg_stat_ssl where pid = 362; -[ RECORD 1 ]-+ pid   | 362 ssl   | t version   | TLSv1.2 cipher    | ECDHE-RSA-AES256-GCM-SHA384 bits  | 256 compression   | f client_dn | client_serial | i

Re: Autovacuum on Partitioned Tables

On 11/1/22 10:11, Ryan Ruenroeng wrote:T Thanks all for your responses. We have a couple of tables. Each with 50-70mil rows currently, but they are expected to grow. Partitioning seems to be a better long-term strategy, queries to these tables, using their existing indexes, leaves them basicall

Re: Delete a table automatic?

Adrian Klaver writes: > On 10/31/22 18:44, 黄宁 wrote: >> I now have two tables named A and B. Table B is calculated based on the >> data of table A. I wonder if table B can be automatically deleted when >> table A is deleted？ > The only thing I can think of is a sql_drop event trigger: I wonder

Re: Autovacuum on Partitioned Tables

Thanks all for your responses. We have a couple of tables. Each with 50-70mil rows currently, but they are expected to grow. Partitioning seems to be a better long-term strategy, queries to these tables, using their existing indexes, leaves them basically unusable (lng run times). FYI, we are

Re: Delete a table automatic?

Hi, I too agree with Adrian Klaver, the trigger is the only option Thanks, V Muralidharan +91 9940302900 On Tue, 1 Nov 2022, 19:46 Peter J. Holzer, wrote: > On 2022-11-01 07:41:14 -0600, Rob Sargent wrote: > > On 11/1/22 03:31, jian he wrote: > > > > On Tue, Nov 1, 2022 at 2:33 PM 黄宁 wr

Re: Delete a table automatic?

On 10/31/22 18:44, 黄宁 wrote: I now have two tables named A and B. Table B is calculated based on the data of table A. I wonder if table B can be automatically deleted when table A is deleted？ The only thing I can think of is a sql_drop event trigger: https://www.postgresql.org/docs/current/f

Re: Delete a table automatic?

On 2022-11-01 07:41:14 -0600, Rob Sargent wrote: > On 11/1/22 03:31, jian he wrote: > > On Tue, Nov 1, 2022 at 2:33 PM 黄宁 wrote: > > I now have two tables named A and B. Table B is calculated based on > the > data of table A. I wonder if table B can be automatically deleted

Re: Delete a table automatic?

On 11/1/22 03:31, jian he wrote: On Tue, Nov 1, 2022 at 2:33 PM 黄宁 wrote: I now have two tables named A and B. Table B is calculated based on the data of table A. I wonder if table B can be automatically deleted when table A is deleted？ Your question seems not that specific. You

Re: Delete a table automatic?

On Tue, Nov 1, 2022 at 2:33 PM 黄宁 wrote: > I now have two tables named A and B. Table B is calculated based on the > data of table A. I wonder if table B can be automatically deleted when > table A is deleted？ > Your question seems not that specific. You can use https://dbfiddle.uk/btGcOH30 to s

Re: PQconsumeinput() may close the fd

21.10.2022, 17:40, "Tom Lane" :Laurenz Albe writes: On Fri, 2022-10-21 at 07:27 +0300, Vasily Kulikov wrote: The problem is that sometimes PQconsumeInput() may close the connectionWhat I'd suggest doing is checking for PQstatus(conn) == CONNECTION_BAD,or else directly rec

Delete a table automatic?

I now have two tables named A and B. Table B is calculated based on the data of table A. I wonder if table B can be automatically deleted when table A is deleted？

Re: Autovacuum on Partitioned Tables

On 10/31/22 23:05, Tom Lane wrote: [snip] TBH, if you've got 50m rows, I'm not sure you need partitions at all. Big rows (i.e. document storage tables with bytea or xml fields) can make databases explode in size even with only 50M rows. (Yes, I know the arguments against it, but it works qui