Re: pgq is one of the most underrated pg related stuff

Just this week I was researching the current market of queuing solutions, and PgQ showed up on the radar with slides from a distant past [0], and unfortunately the Wiki article [1] that linked to [2] needs an update since the link doesn't work anymore :/ I'd love if somebody could give a bit

Re: Operator is not unique

On 9/27/19 2:44 PM, PegoraroF10 wrote: oprname oprkind oprleft oprrightoprresult oprcode + b 170022832283pg_catalog.day_inc + b 228317002283pg_catalog.day_inc Not sure if it will provide any useful informa

Re: Operator is not unique

On 9/27/19 2:44 PM, PegoraroF10 wrote: oprname oprkind oprleft oprrightoprresult oprcode + b 170022832283pg_catalog.day_inc + b 228317002283pg_catalog.day_inc In addition to Tom's comment about above, have

Re: Operator is not unique

PegoraroF10 writes: > oprname oprkind oprleft oprright > oprresult oprcode > + b 170022832283pg_catalog.day_inc > + b 228317002283pg_catalog.day_inc Hm, I wonder what that is. It'd evidently m

Re: steps of a sql

PegoraroF10 writes: > Some days ago one of my customers claimed that one of his queries were > spending too much time. Then on postgres log it appears really strange. That > query doesn´t usually appears as parse, sometimes only as execute, because > it tooks almost all times less than 500ms. But

Re: Operator is not unique

oprname oprkind oprleft oprright oprresult oprcode + l 0 20 20 int8up + l 0 21 21 int2up + l 0 23 23 int4up + l 0 700

steps of a sql

Some days ago one of my customers claimed that one of his queries were spending too much time. Then on postgres log it appears really strange. That query doesn´t usually appears as parse, sometimes only as execute, because it tooks almost all times less than 500ms. But on that day something happene

Re: "Failed to connect to Postgres database"

On 9/27/19 11:19 AM, Marco Ippolito wrote: Sorry again, I was cheering up too quickly. With this configuration in fabric-ca-server-config.yaml :    db:   type: postgres   datasource: host=localhost port=5433 user=postgres password=1234 dbname=fabmnet_ca sslmode=disable   tls:  

Re: "Failed to connect to Postgres database"

On 9/27/19 11:02 AM, Marco Ippolito wrote: Thank you very much Adrian. Two things: 1)  Why if I just specify through port the cluster and the host connection I connect correctly with SSL,  but if I specify also the database and the user it connects it doesn't usel SSL connection, or at least

Re: incoherent dead tuples between pg_stat_user_tables and pgstattuple?

On Fri, Sep 27, 2019 at 4:43 PM Tom Lane wrote: > > I'm not suggesting any specific scenario, because you haven't presented > any evidence as to when those counts became off. I'm just saying that > there are plenty of possible mechanisms for them to become so. So far autovacuum seems the main r

Re: "Failed to connect to Postgres database"

Sorry again, I was cheering up too quickly. With this configuration in fabric-ca-server-config.yaml : db: type: postgres datasource: host=localhost port=5433 user=postgres password=1234 dbname=fabmnet_ca sslmode=disable tls: enabled: false certfiles: cli

Re: "Failed to connect to Postgres database"

Thank you very much Adrian. Two things: 1) Why if I just specify through port the cluster and the host connection I connect correctly with SSL, but if I specify also the database and the user it connects it doesn't usel SSL connection, or at least it doesn't say it uses SSL? : (base) postgres@p

Re: pgq is one of the most underrated pg related stuff

pgq is great, I use it to ship particular records to kafka, but I'm planning on switching to debezium to take advantage of wal logical decoding with wal2json. Cheers. On Wed, Sep 25, 2019 at 5:18 AM Миша Тюрин wrote: > > Ok! How are you doing on (with)without pgq? > > // another underrated was m

Re: "Failed to connect to Postgres database"

On 9/27/19 8:20 AM, Marco Ippolito wrote: Correction of my previous email : This is the correct ssl connection, not the one before via socket: A tip, when troubleshooting be as explicit as possible in your command line usage. So for below explicitly state the -d postgres -U postgres. This wi

Re: pg12 rc1 on CentOS8 depend python2

Thank you for the reply. I understand that contrib package depend libpython. > Another idea might be to bundle them into the plpython package > instead of contrib (and similarly for the plperl transforms). I think that this idea sounds good. If I don't use plpython, it is happy for me that don't

Re: "Failed to connect to Postgres database"

Correction of my previous email : This is the correct ssl connection, not the one before via socket: (base) postgres@pc:~$ psql -p5433 -h localhost Password for user postgres: psql (11.5 (Ubuntu 11.5-1.pgdg18.04+1)) SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, com

Re: "Failed to connect to Postgres database"

Hi Adrian, thanks to your kind explanation I discovered that I can connect to the db without explicitly calling the belonging cluster: (base) postgres@pc:~$ psql -p5433 -d fabmnet_ca psql (11.5 (Ubuntu 11.5-1.pgdg18.04+1)) Type "help" for help. fabmnet_ca=# \conninfo You are connected to databas

Re: incoherent dead tuples between pg_stat_user_tables and pgstattuple?

Luca Ferrari writes: > On Fri, Sep 27, 2019 at 3:52 PM Tom Lane wrote: >> n_live_tup/n_dead_tup should not be thought to be better than >> approximations. Most operations adjust them only incrementally, >> and messages to the stats collector can get dropped entirely >> under heavy load, causing

Re: "Failed to connect to Postgres database"

On 9/27/19 5:58 AM, Marco Ippolito wrote: Thanks Daniel. After adding the password, now ssh connection to the cluster fabmnet works: You might want to take a look at: https://help.ubuntu.com/lts/serverguide/postgresql.html And may be the fact the it's compulsory to add a password is testifie

Re: incoherent dead tuples between pg_stat_user_tables and pgstattuple?

On Fri, Sep 27, 2019 at 3:52 PM Tom Lane wrote: > n_live_tup/n_dead_tup should not be thought to be better than > approximations. Most operations adjust them only incrementally, > and messages to the stats collector can get dropped entirely > under heavy load, causing deltas to go missing. There

Re: pg12 rc1 on CentOS8 depend python2

Re: Tom Lane 2019-09-27 <19495.1569591...@sss.pgh.pa.us> > Another idea might be to bundle them into the plpython package > instead of contrib (and similarly for the plperl transforms). Fwiw, the Debian packages do that. Christoph

Re: incoherent dead tuples between pg_stat_user_tables and pgstattuple?

Luca Ferrari writes: > running 11.5 I've some misconception about pgstatuple: it seems it > lags behind normal statistics. n_live_tup/n_dead_tup should not be thought to be better than approximations. Most operations adjust them only incrementally, and messages to the stats collector can get dro

Re: pg12 rc1 on CentOS8 depend python2

keisuke kuroda writes: > Even if I don't need to install plpythonu, > RPM package includes "CONFIGURE = --with-python". > Therefore I think that I need to install python2 when RPM install. > Is my understanding correct? The core server package shouldn't have any python dependency. It doesn't sur

Re: "Failed to connect to Postgres database"

Thanks Daniel. After adding the password, now ssh connection to the cluster fabmnet works: postgres=# \l List of databases Name| Owner | Encoding | Collate | Ctype | Access privileges +--+--+-+-+-

Re: pgq is one of the most underrated pg related stuff

On 27/9/19 1:41 μ.μ., Luca Ferrari wrote: On Wed, Sep 25, 2019 at 12:18 PM Миша Тюрин wrote: // another underrated was multicorn. Is it still alive? Apparently it is , even if it is breathing slow .

Re: Monitor Postgres database status on Docker

Hi Daulat, El mar., 24 de septiembre de 2019 07:05, Daulat Ram < daulat@exponential.com> escribió: > Thanks but how we can use it for docker container. > You have basically 2 ways: 1) Publish the port 5432 on the container and access it from the host, or 2) Use "docker exec" to run the com

Re: "Failed to connect to Postgres database"

Marco Ippolito wrote: > (base) postgres@pc:~$ psql --cluster 11/fabmnet -h localhost > Password for user postgres: > psql: FATAL: password authentication failed for user "postgres" > FATAL: password authentication failed for user "postgres" Did you set a password for the postgres user i

Re: pgq is one of the most underrated pg related stuff

On Wed, Sep 25, 2019 at 12:18 PM Миша Тюрин wrote: > // another underrated was multicorn. Is it still alive? Apparently it is , even if it is breathing slow . Luca

Re: "Failed to connect to Postgres database"

I need to understand this: I dropped the previous fabmnet cluster and re-created a new one: (base) postgres@pc:~$ pg_lsclusters Ver Cluster Port Status OwnerData directory Log file 11 fabmnet 5433 online postgres /var/lib/postgresql/11/fabmnet /var/log/postgresql/postgresql-1

incoherent dead tuples between pg_stat_user_tables and pgstattuple?

Hello, running 11.5 I've some misconception about pgstatuple: it seems it lags behind normal statistics. I've almost double a table with an update. The result is: testdb=# select n_live_tup, n_dead_tup, last_autovacuum, last_autoanalyze from pg_stat_user_tables where relname = 'foo'; -[ RECORD 1 ]