Re: Consulta sobre standard_conforming_strings

[felix gonzales]

gracias Horacio por tu aporte

On Thu, Mar 14, 2024 at 8:03 PM Horacio Miranda  wrote:

> no creo que esa persona sepa bien lo que es SQL Injection.
>
> Si bien un parametro puede hacer que sea más restrictivo el postgresql el
> concepto es simple, Prepared Statements. Si tu aplicación no las tiene, te
> pueden hacer SQL Injection
>
> SQL Injection | OWASP Foundation
> <https://owasp.org/www-community/attacks/SQL_Injection>
> owasp.org <https://owasp.org/www-community/attacks/SQL_Injection>
> [image: favicon.ico]
> <https://owasp.org/www-community/attacks/SQL_Injection>
> <https://owasp.org/www-community/attacks/SQL_Injection>
>
> Este parametro “standard_conforming_strings” se refiere a como tratar el
> caracter especial backslash “\” usualmente es un caracter comoding para
> indicar en expresiones regulares, trata el sigueinte caracter como string
> no como algo especial. por lo que dice es algo forzado en on y se puede
> apagar.
>
> Esto no tiene relación con un SQL Injection.
>
>
> On 14/03/2024, at 9:47 PM, felix gonzales  wrote:
>
> Buenas noches.
>
> Esperaba algún comentario a la consulta, que hice en la mañana, ya que
> necesito brindar una respuesta a las afirmaciones hechas por otra persona
> en mi empresa quien manifiesta que el parámetro
> "standard_conforming_strings en off, pondría en riesgo el servidor al nivel
> de dejar abierta la amenaza de  provocar inyecciones de SQL y problemas de
> seguridad similares"
> y hace referencia a esta documentación:
> https://www.postgresql.org/docs/14/sql-syntax-lexical.html
>
> Revisando dicho enlace hallé lo siguiente:
>
> "4.1.2.3. String Constants With Unicode Escapes
> .
> Also, the Unicode escape syntax for string constants only works when the
> configuration parameter standard_conforming_strings
> <https://www.postgresql.org/docs/14/runtime-config-compatible.html#GUC-STANDARD-CONFORMING-STRINGS>
>  is
> turned on. This is because otherwise this syntax could confuse clients that
> parse the SQL statements to the point that it could lead to SQL injections
> and similar security issues. If the parameter is set to off, this syntax
> will be rejected with an error message."
>
> Este párrafo no me queda muy claro (en la última línea indica que si el
> parámetro está en off  la sintaxis se rechaza con un mensaje de error),
> por ello pedía opiniones.
>
> Tengo claro que actualizar la función es lo más conveniente para evitar
> mover el parámetro. Pero también necesito sustentar una respuesta que
> estando en off no es tan grave como lo indica o me equivoco?.
>
>
> On Thu, Mar 14, 2024 at 10:55 AM felix gonzales 
> wrote:
>
>> Buenos días grupo
>> Comentarles que tengo una base de datos con postgres-14, dentro de la
>> cual hay una función migrada desde postgres-9. Para que funcione
>> adecuadamente  debo cambiar el parámetro "standard_conforming_strings" a
>> off  y así evitar el warning.
>>
>> consulta: El dejar el parámetro en off, pondría en riesgo mi servidor al
>> nivel de dejar abierta la amenaza de  provocar inyecciones de SQL y
>> problemas de seguridad similares?
>>
>> Quedo atento a sus comentarios.
>>
>> Gracias
>> --
>> Felix Gonzales
>>
>>
>
> --
> Felix Gonzales
>
>
>

-- 
Felix Gonzales


favicon.ico
Description: Binary data

Re: Consulta sobre standard_conforming_strings

[Horacio Miranda]

no creo que esa persona sepa bien lo que es SQL Injection.

Si bien un parametro puede hacer que sea más restrictivo el postgresql el 
concepto es simple, Prepared Statements. Si tu aplicación no las tiene, te 
pueden hacer SQL Injection

https://owasp.org/www-community/attacks/SQL_Injection

Este parametro “standard_conforming_strings” se refiere a como tratar el 
caracter especial backslash “\” usualmente es un caracter comoding para indicar 
en expresiones regulares, trata el sigueinte caracter como string no como algo 
especial. por lo que dice es algo forzado en on y se puede apagar.

Esto no tiene relación con un SQL Injection.


> On 14/03/2024, at 9:47 PM, felix gonzales  wrote:
> 
> Buenas noches.
> 
> Esperaba algún comentario a la consulta, que hice en la mañana, ya que 
> necesito brindar una respuesta a las afirmaciones hechas por otra persona en 
> mi empresa quien manifiesta que el parámetro "standard_conforming_strings en 
> off, pondría en riesgo el servidor al nivel de dejar abierta la amenaza de  
> provocar inyecciones de SQL y problemas de seguridad similares" 
> y hace referencia a esta documentación:  
> https://www.postgresql.org/docs/14/sql-syntax-lexical.html
> 
> Revisando dicho enlace hallé lo siguiente:
> 
> "4.1.2.3. String Constants With Unicode Escapes
> .
> Also, the Unicode escape syntax for string constants only works when the 
> configuration parameter standard_conforming_strings 
> <https://www.postgresql.org/docs/14/runtime-config-compatible.html#GUC-STANDARD-CONFORMING-STRINGS>
>  is turned on. This is because otherwise this syntax could confuse clients 
> that parse the SQL statements to the point that it could lead to SQL 
> injections and similar security issues. If the parameter is set to off, this 
> syntax will be rejected with an error message."
> 
> Este párrafo no me queda muy claro (en la última línea indica que si el 
> parámetro está en off  la sintaxis se rechaza con un mensaje de error),  por 
> ello pedía opiniones.
> 
> Tengo claro que actualizar la función es lo más conveniente para evitar mover 
> el parámetro. Pero también necesito sustentar una respuesta que estando en 
> off no es tan grave como lo indica o me equivoco?.
> 
> 
> On Thu, Mar 14, 2024 at 10:55 AM felix gonzales  <mailto:jfgonza...@gmail.com>> wrote:
>> Buenos días grupo
>> Comentarles que tengo una base de datos con postgres-14, dentro de la cual 
>> hay una función migrada desde postgres-9. Para que funcione adecuadamente  
>> debo cambiar el parámetro "standard_conforming_strings" a off  y así evitar 
>> el warning.
>> 
>> consulta: El dejar el parámetro en off, pondría en riesgo mi servidor al 
>> nivel de dejar abierta la amenaza de  provocar inyecciones de SQL y 
>> problemas de seguridad similares?
>> 
>> Quedo atento a sus comentarios.
>> 
>> Gracias
>> -- 
>> Felix Gonzales
>> 
> 
> 
> -- 
> Felix Gonzales
> 

Re: Consulta sobre standard_conforming_strings

[felix gonzales]

Buenas noches.

Esperaba algún comentario a la consulta, que hice en la mañana, ya que
necesito brindar una respuesta a las afirmaciones hechas por otra persona
en mi empresa quien manifiesta que el parámetro
"standard_conforming_strings en off, pondría en riesgo el servidor al nivel
de dejar abierta la amenaza de  provocar inyecciones de SQL y problemas de
seguridad similares"
y hace referencia a esta documentación:
https://www.postgresql.org/docs/14/sql-syntax-lexical.html

Revisando dicho enlace hallé lo siguiente:

"4.1.2.3. String Constants With Unicode Escapes
.
Also, the Unicode escape syntax for string constants only works when the
configuration parameter standard_conforming_strings
<https://www.postgresql.org/docs/14/runtime-config-compatible.html#GUC-STANDARD-CONFORMING-STRINGS>
is
turned on. This is because otherwise this syntax could confuse clients that
parse the SQL statements to the point that it could lead to SQL injections
and similar security issues. If the parameter is set to off, this syntax
will be rejected with an error message."

Este párrafo no me queda muy claro (en la última línea indica que si el
parámetro está en off  la sintaxis se rechaza con un mensaje de error),
por ello pedía opiniones.

Tengo claro que actualizar la función es lo más conveniente para evitar
mover el parámetro. Pero también necesito sustentar una respuesta que
estando en off no es tan grave como lo indica o me equivoco?.


On Thu, Mar 14, 2024 at 10:55 AM felix gonzales 
wrote:

> Buenos días grupo
> Comentarles que tengo una base de datos con postgres-14, dentro de la cual
> hay una función migrada desde postgres-9. Para que funcione adecuadamente
> debo cambiar el parámetro "standard_conforming_strings" a off  y así evitar
> el warning.
>
> consulta: El dejar el parámetro en off, pondría en riesgo mi servidor al
> nivel de dejar abierta la amenaza de  provocar inyecciones de SQL y
> problemas de seguridad similares?
>
> Quedo atento a sus comentarios.
>
> Gracias
> --
> Felix Gonzales
>
>

-- 
Felix Gonzales

Consulta sobre standard_conforming_strings

[felix gonzales]

Buenos días grupo
Comentarles que tengo una base de datos con postgres-14, dentro de la cual
hay una función migrada desde postgres-9. Para que funcione adecuadamente
debo cambiar el parámetro "standard_conforming_strings" a off  y así evitar
el warning.

consulta: El dejar el parámetro en off, pondría en riesgo mi servidor al
nivel de dejar abierta la amenaza de  provocar inyecciones de SQL y
problemas de seguridad similares?

Quedo atento a sus comentarios.

Gracias
-- 
Felix Gonzales

Re: Consulta postgres enterprise

[Carlos T. Groero Carmona]

Hola Fernando,

Yo uso open source, pero se que EDB tiene una version de postgres
enterprise con suporte incluido. Las versiones van casi siempre una por
atras de la comunidad y le dan soporte a versiones que ya la comunidad no
soporta comp Pg 9.6 y pg10.

Yo lo que hice fue usar open source,  porque ya estaba asi en mi trabajo,
y despues compramos un plan de soporte con edb que brinda soporte a
PostgreSQL incluso si es open source.

Sin embargo creo que debes preguntarle a tu cliente si ya tiene definido
quien va a proveer esa version enterprise, si no te recomendaria EDB.

Sobre la diferencia entre la fuente Open Source vs Enterprises la verdad no
la he revisado mucho,  se que EDB brinda su propio repositorio con su
version de Postgres pero no creo que le haga mucho mas que decir...esta es
mi version y todo lo que esta aqui yo le doy soporte si tienes algun bug
pues EDB tiene dentro de su nomina grandes contribuidores del codigo
original y adquirio 2dn Quadrant por l tanto tiene la capacidad de arreglar
cualquier bug en el codigo fuente de postgres.

Vuelvo y te repito,  no he hecho ningun analisis sobre la diferencia,  pero
es la impresion que tengo basado a un poco de busqueda,  el portal de EDB y
2dn Quadrant.

Saludos,
Carlos


On Mon, Jul 24, 2023, 12:03 PM Romero, Fernando <
fernando.rom...@trenesargentinos.gob.ar> wrote:

> Hola como están.
>
> Tengo que hacer una instalación de replica entre 2 nodos, 1 primario y
> otro secundario (standby) y que tengan la posibilidad de failover
>
> Voy a usar streaming replication, el cliente me dice que quiere usar la
> version de enterprise, nunca use esa versión.
>
> Alguien la usa? que diferencia tiene con la open source?
>
>
> Saludos
> “El contenido del presente mensaje (y sus anexos) es privado, confidencial
> y de exclusivo uso para el destinatario referenciado; es de público
> conocimiento que las comunicaciones por medio de Internet no permiten
> asegurar ni garantizar la confidencialidad de los mensajes transmitidos,
> así como tampoco su integridad o su correcta recepción; es por ello que
> SOFSE no se responsabiliza de posibles perjuicios derivados de la captura,
> incorporaciones de virus o cualquier otra manipulación efectuada por
> terceros. Las opiniones expresadas en este mensaje y en los archivos
> adjuntos son propias del remitente y no representan la opinión o políticas
> de SOFSE, salvo que se diga expresamente y el remitente se encuentre
> autorizado para ello”
>

Consulta postgres enterprise

[Romero, Fernando]

Hola como están.

Tengo que hacer una instalación de replica entre 2 nodos, 1 primario y otro 
secundario (standby) y que tengan la posibilidad de failover

Voy a usar streaming replication, el cliente me dice que quiere usar la version 
de enterprise, nunca use esa versión.

Alguien la usa? que diferencia tiene con la open source?


Saludos

"El contenido del presente mensaje (y sus anexos) es privado, confidencial y de 
exclusivo uso para el destinatario referenciado; es de público conocimiento que 
las comunicaciones por medio de Internet no permiten asegurar ni garantizar la 
confidencialidad de los mensajes transmitidos, así como tampoco su integridad o 
su correcta recepción; es por ello que SOFSE no se responsabiliza de posibles 
perjuicios derivados de la captura, incorporaciones de virus o cualquier otra 
manipulación efectuada por terceros. Las opiniones expresadas en este mensaje y 
en los archivos adjuntos son propias del remitente y no representan la opinión 
o políticas de SOFSE, salvo que se diga expresamente y el remitente se 
encuentre autorizado para ello"

Re: Consulta pgbouncer

[Romero, Fernando]

Al pgbouncer.ini le agregue la base


[databases]
postgres = host=127.0.0.1 port=5432 dbname=postgres
pgb_mydb = host=127.0.0.1 port=5432 dbname=mydb


​El manual que seguia no tenia ese dato, grega la base solamente en el 
pgbouncer-database.ini y asi no me funcionaba.

Saludos



De: Horacio Miranda 
Enviado: lunes, 12 de septiembre de 2022 09:50 p.m.
Para: Romero, Fernando
Cc: Hellmuth Vargas; Lista Postgres ES
Asunto: Re: Consulta pgbouncer

Cual era el problema ?

La ideal del foro, es plantear el problema, se plantean soluciones y se 
confirma la solución.

On 13/09/2022, at 12:21 PM, Romero, Fernando 
mailto:fernando.rom...@trenesargentinos.gob.ar>>
 wrote:

​Gracias, lo pude solucionar

De: Horacio Miranda mailto:hmira...@gmail.com>>
Enviado: lunes, 12 de septiembre de 2022 08:37 p.m.
Para: Romero, Fernando
Cc: Hellmuth Vargas; Lista Postgres ES
Asunto: Re: Consulta pgbouncer



On 13/09/2022, at 11:34 AM, Romero, Fernando 
mailto:fernando.rom...@trenesargentinos.gob.ar>>
 wrote:

Hola, gracias por tu respuesta.
Esa parte ya la tengo, pero me da error
Creo que debes revisar la documentación.
https://gpdb.docs.pivotal.io/6-1/admin_guide/access_db/topics/pgbouncer.html

Este es un ejemplo.

[databases]
postgres = host=127.0.0.1 port=5432 dbname=postgres
pgb_mydb = host=127.0.0.1 port=5432 dbname=mydb

[pgbouncer]
pool_mode = session
listen_port = 6543
listen_addr = 127.0.0.1
auth_type = md5
auth_file = users.txt
logfile = pgbouncer.log
pidfile = pgbouncer.pid
admin_users = gpadmin

La sección database es la parte del postgresql, desde el psql debes poder 
conectarte a la base real.
Luego con pgbouncer debes poder conectar el puerto del pgbouncer.


[postgres@postgres4 ~]$ cat /etc/pgbouncer/pgbouncer.database.ini
[databases]
appdb-rw= host=postgres1 dbname=appdb port=6434
[postgres@postgres4 ~]$ psql 'host=localhost dbname=appdb user=appdb 
password=appdb  port=6432'
psql: error: FATAL:  no such database: appdb
[postgres@postgres4 ~]$

​No encuentra la base


De: Hellmuth Vargas mailto:hiv...@gmail.com>>
Enviado: domingo, 11 de septiembre de 2022 02:11 p.m.
Para: Romero, Fernando
Cc: Lista Postgres ES
Asunto: Re: Consulta pgbouncer

Hola

Le hace falta la sesión Database

https://www.pgbouncer.org/config.html#section-databases


El sáb., 10 de septiembre de 2022 1:58 p. m., Romero, Fernando 
mailto:fernando.rom...@trenesargentinos.gob.ar>>
 escribió:
Hola como estan, estoy configurando pgbouncer en un nodo testigo pero no logro 
conectarme
Esta es la conf del pgbouncer

[pgbouncer]

logfile = /var/log/pgbouncer/pgbouncer.log
pidfile = /var/run/pgbouncer/pgbouncer.pid

listen_addr = *
listen_port = 6432
unix_socket_dir = /tmp

auth_type = trust
auth_file = /etc/pgbouncer/userlist.txt
auth_hba_file = /etc/pgbouncer/pg_hba.conf

admin_users = postgres
stats_users = postgres

pool_mode = transaction
server_reset_query = DISCARD ALL

max_client_conn = 100
default_pool_size = 20
min_pool_size = 5
reserve_pool_size = 5
reserve_pool_timeout = 3

log_connections = 1
log_disconnections = 1
log_pooler_errors = 1

Tengo creada la base de datos pero no logro conectarme me tira este error:

[postgres@postgres4 ~]$ psql 'host=192.168.0.55 dbname=appdb user=appdb 
password=appdb  port=6432'
psql: error: FATAL:  no such database: appdb

La ip es del servidor que esta el pgbouncer base de datos existe y el usuario 
tambien
postgres=# \l
Listado de base de datos
  Nombre   |  Dueño   | Codificación |   Collate   |Ctype|  
Privilegios
---+--+--+-+-+---
 appdb | appdb| UTF8 | es_AR.UTF-8 | es_AR.UTF-8 |
 postgres  | postgres | UTF8 | es_AR.UTF-8 | es_AR.UTF-8 |
 repmgr| repmgr   | UTF8 | es_AR.UTF-8 | es_AR.UTF-8 |
 template0 | postgres | UTF8 | es_AR.UTF-8 | es_AR.UTF-8 | =c/postgres  
+
   |  |  | | | 
postgres=CTc/postgres
 template1 | postgres | UTF8 | es_AR.UTF-8 | es_AR.UTF-8 | =c/postgres  
+
   |  |  | | | 
postgres=CTc/postgres
(5 filas)

​En el pg_hba.conf tengo la linea para que permita la conexion
hostappdb   appdb192.168.0.0/24 trust

Y en el pg_hba.conf del pgbouncer
host pgbouncer pgbouncer 192.168.0.0/24 trust

Saludos​





“El contenido del presente mensaje (y sus anexos) es privado, confidencial y de 
exclusivo uso para el destinatario referenciado; es de público conocimiento que 
las comunicaciones por medio de Internet no permiten asegurar ni garantizar la 
confidencialidad de  los mensajes transmitidos, así como tampoco su integridad 
o su correcta recepción; es por ello que SOFSE no se responsabiliza de posibles 
perjuicios derivados de la captura, incorporaci

Re: Consulta pgbouncer

[Horacio Miranda]

Cual era el problema ? 

La ideal del foro, es plantear el problema, se plantean soluciones y se 
confirma la solución.

> On 13/09/2022, at 12:21 PM, Romero, Fernando 
>  wrote:
> 
> ​Gracias, lo pude solucionar
> De: Horacio Miranda mailto:hmira...@gmail.com>>
> Enviado: lunes, 12 de septiembre de 2022 08:37 p.m.
> Para: Romero, Fernando
> Cc: Hellmuth Vargas; Lista Postgres ES
> Asunto: Re: Consulta pgbouncer
>  
> 
> 
>> On 13/09/2022, at 11:34 AM, Romero, Fernando 
>> > <mailto:fernando.rom...@trenesargentinos.gob.ar>> wrote:
>> 
>> Hola, gracias por tu respuesta.
>> Esa parte ya la tengo, pero me da error
> Creo que debes revisar la documentación.
> https://gpdb.docs.pivotal.io/6-1/admin_guide/access_db/topics/pgbouncer.html 
> <https://gpdb.docs.pivotal.io/6-1/admin_guide/access_db/topics/pgbouncer.html>
> 
> Este es un ejemplo. 
> [databases]
> postgres = host=127.0.0.1 port=5432 dbname=postgres
> pgb_mydb = host=127.0.0.1 port=5432 dbname=mydb
> 
> [pgbouncer]
> pool_mode = session
> listen_port = 6543
> listen_addr = 127.0.0.1
> auth_type = md5
> auth_file = users.txt
> logfile = pgbouncer.log
> pidfile = pgbouncer.pid
> admin_users = gpadmin
> La sección database es la parte del postgresql, desde el psql debes poder 
> conectarte a la base real.
> Luego con pgbouncer debes poder conectar el puerto del pgbouncer.
> 
> 
>> [postgres@postgres4 ~]$ cat /etc/pgbouncer/pgbouncer.database.ini
>> [databases]
>> appdb-rw= host=postgres1 dbname=appdb port=6434
>> [postgres@postgres4 ~]$ psql 'host=localhost dbname=appdb user=appdb 
>> password=appdb  port=6432'
>> psql: error: FATAL:  no such database: appdb
>> [postgres@postgres4 ~]$
>> 
>> ​No encuentra la base
>> 
>> De: Hellmuth Vargas mailto:hiv...@gmail.com>>
>> Enviado: domingo, 11 de septiembre de 2022 02:11 p.m.
>> Para: Romero, Fernando
>> Cc: Lista Postgres ES
>> Asunto: Re: Consulta pgbouncer
>>  
>> Hola
>> 
>> Le hace falta la sesión Database 
>> 
>> https://www.pgbouncer.org/config.html#section-databases 
>> <https://www.pgbouncer.org/config.html#section-databases>
>> 
>> 
>> El sáb., 10 de septiembre de 2022 1:58 p. m., Romero, Fernando 
>> > <mailto:fernando.rom...@trenesargentinos.gob.ar>> escribió:
>> Hola como estan, estoy configurando pgbouncer en un nodo testigo pero no 
>> logro conectarme
>> Esta es la conf del pgbouncer
>> 
>> [pgbouncer]
>> 
>> logfile = /var/log/pgbouncer/pgbouncer.log
>> pidfile = /var/run/pgbouncer/pgbouncer.pid
>> 
>> listen_addr = *
>> listen_port = 6432
>> unix_socket_dir = /tmp
>> 
>> auth_type = trust
>> auth_file = /etc/pgbouncer/userlist.txt
>> auth_hba_file = /etc/pgbouncer/pg_hba.conf
>> 
>> admin_users = postgres
>> stats_users = postgres
>> 
>> pool_mode = transaction
>> server_reset_query = DISCARD ALL
>> 
>> max_client_conn = 100
>> default_pool_size = 20
>> min_pool_size = 5
>> reserve_pool_size = 5
>> reserve_pool_timeout = 3
>> 
>> log_connections = 1
>> log_disconnections = 1
>> log_pooler_errors = 1
>> 
>> Tengo creada la base de datos pero no logro conectarme me tira este error:
>> 
>> [postgres@postgres4 ~]$ psql 'host=192.168.0.55 dbname=appdb user=appdb 
>> password=appdb  port=6432'
>> psql: error: FATAL:  no such database: appdb
>> 
>> La ip es del servidor que esta el pgbouncer base de datos existe y el 
>> usuario tambien
>> postgres=# \l
>> Listado de base de datos
>>   Nombre   |  Dueño   | Codificación |   Collate   |Ctype|  
>> Privilegios
>> ---+--+--+-+-+---
>>  appdb | appdb| UTF8 | es_AR.UTF-8 | es_AR.UTF-8 |
>>  postgres  | postgres | UTF8 | es_AR.UTF-8 | es_AR.UTF-8 |
>>  repmgr| repmgr   | UTF8 | es_AR.UTF-8 | es_AR.UTF-8 |
>>  template0 | postgres | UTF8 | es_AR.UTF-8 | es_AR.UTF-8 | 
>> =c/postgres  +
>>|  |  | | | 
>> postgres=CTc/postgres
>>  template1 | postgres | UTF8 | es_AR.UTF-8 | es_AR.UTF-8 | 
>> =c/postgres  +
>>|  |  | | | 
>> postgres=CTc/postgres
>> (5 filas)
>> 
>> ​En el pg_hba.conf tengo la linea para que permita la conexion
>> hostappdb   appdb192.16

Re: Consulta pgbouncer

[Romero, Fernando]

​Gracias, lo pude solucionar


De: Horacio Miranda 
Enviado: lunes, 12 de septiembre de 2022 08:37 p.m.
Para: Romero, Fernando
Cc: Hellmuth Vargas; Lista Postgres ES
Asunto: Re: Consulta pgbouncer



On 13/09/2022, at 11:34 AM, Romero, Fernando 
mailto:fernando.rom...@trenesargentinos.gob.ar>>
 wrote:

Hola, gracias por tu respuesta.
Esa parte ya la tengo, pero me da error
Creo que debes revisar la documentación.
https://gpdb.docs.pivotal.io/6-1/admin_guide/access_db/topics/pgbouncer.html

Este es un ejemplo.

[databases]
postgres = host=127.0.0.1 port=5432 dbname=postgres
pgb_mydb = host=127.0.0.1 port=5432 dbname=mydb

[pgbouncer]
pool_mode = session
listen_port = 6543
listen_addr = 127.0.0.1
auth_type = md5
auth_file = users.txt
logfile = pgbouncer.log
pidfile = pgbouncer.pid
admin_users = gpadmin

La sección database es la parte del postgresql, desde el psql debes poder 
conectarte a la base real.
Luego con pgbouncer debes poder conectar el puerto del pgbouncer.


[postgres@postgres4 ~]$ cat /etc/pgbouncer/pgbouncer.database.ini
[databases]
appdb-rw= host=postgres1 dbname=appdb port=6434
[postgres@postgres4 ~]$ psql 'host=localhost dbname=appdb user=appdb 
password=appdb  port=6432'
psql: error: FATAL:  no such database: appdb
[postgres@postgres4 ~]$

​No encuentra la base


De: Hellmuth Vargas mailto:hiv...@gmail.com>>
Enviado: domingo, 11 de septiembre de 2022 02:11 p.m.
Para: Romero, Fernando
Cc: Lista Postgres ES
Asunto: Re: Consulta pgbouncer

Hola

Le hace falta la sesión Database

https://www.pgbouncer.org/config.html#section-databases


El sáb., 10 de septiembre de 2022 1:58 p. m., Romero, Fernando 
mailto:fernando.rom...@trenesargentinos.gob.ar>>
 escribió:
Hola como estan, estoy configurando pgbouncer en un nodo testigo pero no logro 
conectarme
Esta es la conf del pgbouncer

[pgbouncer]

logfile = /var/log/pgbouncer/pgbouncer.log
pidfile = /var/run/pgbouncer/pgbouncer.pid

listen_addr = *
listen_port = 6432
unix_socket_dir = /tmp

auth_type = trust
auth_file = /etc/pgbouncer/userlist.txt
auth_hba_file = /etc/pgbouncer/pg_hba.conf

admin_users = postgres
stats_users = postgres

pool_mode = transaction
server_reset_query = DISCARD ALL

max_client_conn = 100
default_pool_size = 20
min_pool_size = 5
reserve_pool_size = 5
reserve_pool_timeout = 3

log_connections = 1
log_disconnections = 1
log_pooler_errors = 1

Tengo creada la base de datos pero no logro conectarme me tira este error:

[postgres@postgres4 ~]$ psql 'host=192.168.0.55 dbname=appdb user=appdb 
password=appdb  port=6432'
psql: error: FATAL:  no such database: appdb

La ip es del servidor que esta el pgbouncer base de datos existe y el usuario 
tambien
postgres=# \l
Listado de base de datos
  Nombre   |  Dueño   | Codificación |   Collate   |Ctype|  
Privilegios
---+--+--+-+-+---
 appdb | appdb| UTF8 | es_AR.UTF-8 | es_AR.UTF-8 |
 postgres  | postgres | UTF8 | es_AR.UTF-8 | es_AR.UTF-8 |
 repmgr| repmgr   | UTF8 | es_AR.UTF-8 | es_AR.UTF-8 |
 template0 | postgres | UTF8 | es_AR.UTF-8 | es_AR.UTF-8 | =c/postgres  
+
   |  |  | | | 
postgres=CTc/postgres
 template1 | postgres | UTF8 | es_AR.UTF-8 | es_AR.UTF-8 | =c/postgres  
+
   |  |  | | | 
postgres=CTc/postgres
(5 filas)

​En el pg_hba.conf tengo la linea para que permita la conexion
hostappdb   appdb192.168.0.0/24 trust

Y en el pg_hba.conf del pgbouncer
host pgbouncer pgbouncer 192.168.0.0/24 trust

Saludos​





“El contenido del presente mensaje (y sus anexos) es privado, confidencial y de 
exclusivo uso para el destinatario referenciado; es de público conocimiento que 
las comunicaciones por medio de Internet no permiten asegurar ni garantizar la 
confidencialidad de los mensajes transmitidos, así como tampoco su integridad o 
su correcta recepción; es por ello que SOFSE no se responsabiliza de posibles 
perjuicios derivados de la captura, incorporaciones de virus o cualquier otra 
manipulación efectuada por terceros. Las opiniones expresadas en este mensaje y 
en los archivos adjuntos son propias del remitente y no representan la opinión 
o políticas de SOFSE, salvo que se diga expresamente y el remitente se 
encuentre autorizado para ello”
“El contenido del presente mensaje (y sus anexos) es privado, confidencial y de 
exclusivo uso para el destinatario referenciado; es de público conocimiento que 
las comunicaciones por medio de Internet no permiten asegurar ni garantizar la 
confidencialidad de los mensajes transmitidos, así como tampoco su integridad o 
su correcta recepción; es por ello que SOFSE no se responsabiliza de posibles 
perjuicios derivados de la captura, incorpor

Re: Consulta pgbouncer

[Horacio Miranda]

> On 13/09/2022, at 11:34 AM, Romero, Fernando 
>  wrote:
> 
> Hola, gracias por tu respuesta.
> Esa parte ya la tengo, pero me da error
Creo que debes revisar la documentación.
https://gpdb.docs.pivotal.io/6-1/admin_guide/access_db/topics/pgbouncer.html

Este es un ejemplo. 
[databases]
postgres = host=127.0.0.1 port=5432 dbname=postgres
pgb_mydb = host=127.0.0.1 port=5432 dbname=mydb

[pgbouncer]
pool_mode = session
listen_port = 6543
listen_addr = 127.0.0.1
auth_type = md5
auth_file = users.txt
logfile = pgbouncer.log
pidfile = pgbouncer.pid
admin_users = gpadmin
La sección database es la parte del postgresql, desde el psql debes poder 
conectarte a la base real.
Luego con pgbouncer debes poder conectar el puerto del pgbouncer.


> [postgres@postgres4 ~]$ cat /etc/pgbouncer/pgbouncer.database.ini
> [databases]
> appdb-rw= host=postgres1 dbname=appdb port=6434
> [postgres@postgres4 ~]$ psql 'host=localhost dbname=appdb user=appdb 
> password=appdb  port=6432'
> psql: error: FATAL:  no such database: appdb
> [postgres@postgres4 ~]$
> 
> ​No encuentra la base
> 
> De: Hellmuth Vargas mailto:hiv...@gmail.com>>
> Enviado: domingo, 11 de septiembre de 2022 02:11 p.m.
> Para: Romero, Fernando
> Cc: Lista Postgres ES
> Asunto: Re: Consulta pgbouncer
>  
> Hola
> 
> Le hace falta la sesión Database 
> 
> https://www.pgbouncer.org/config.html#section-databases 
> <https://www.pgbouncer.org/config.html#section-databases>
> 
> 
> El sáb., 10 de septiembre de 2022 1:58 p. m., Romero, Fernando 
>  <mailto:fernando.rom...@trenesargentinos.gob.ar>> escribió:
> Hola como estan, estoy configurando pgbouncer en un nodo testigo pero no 
> logro conectarme
> Esta es la conf del pgbouncer
> 
> [pgbouncer]
> 
> logfile = /var/log/pgbouncer/pgbouncer.log
> pidfile = /var/run/pgbouncer/pgbouncer.pid
> 
> listen_addr = *
> listen_port = 6432
> unix_socket_dir = /tmp
> 
> auth_type = trust
> auth_file = /etc/pgbouncer/userlist.txt
> auth_hba_file = /etc/pgbouncer/pg_hba.conf
> 
> admin_users = postgres
> stats_users = postgres
> 
> pool_mode = transaction
> server_reset_query = DISCARD ALL
> 
> max_client_conn = 100
> default_pool_size = 20
> min_pool_size = 5
> reserve_pool_size = 5
> reserve_pool_timeout = 3
> 
> log_connections = 1
> log_disconnections = 1
> log_pooler_errors = 1
> 
> Tengo creada la base de datos pero no logro conectarme me tira este error:
> 
> [postgres@postgres4 ~]$ psql 'host=192.168.0.55 dbname=appdb user=appdb 
> password=appdb  port=6432'
> psql: error: FATAL:  no such database: appdb
> 
> La ip es del servidor que esta el pgbouncer base de datos existe y el usuario 
> tambien
> postgres=# \l
> Listado de base de datos
>   Nombre   |  Dueño   | Codificación |   Collate   |Ctype|  
> Privilegios
> ---+--+--+-+-+---
>  appdb | appdb| UTF8 | es_AR.UTF-8 | es_AR.UTF-8 |
>  postgres  | postgres | UTF8 | es_AR.UTF-8 | es_AR.UTF-8 |
>  repmgr| repmgr   | UTF8 | es_AR.UTF-8 | es_AR.UTF-8 |
>  template0 | postgres | UTF8 | es_AR.UTF-8 | es_AR.UTF-8 | 
> =c/postgres  +
>|  |  | | | 
> postgres=CTc/postgres
>  template1 | postgres | UTF8 | es_AR.UTF-8 | es_AR.UTF-8 | 
> =c/postgres  +
>|  |  | | | 
> postgres=CTc/postgres
> (5 filas)
> 
> ​En el pg_hba.conf tengo la linea para que permita la conexion
> hostappdb   appdb192.168.0.0/24 
>  trust
> 
> Y en el pg_hba.conf del pgbouncer
> host pgbouncer pgbouncer 192.168.0.0/24 
>  trust
> 
> Saludos​
> 
> 
> 
> 
> 
> “El contenido del presente mensaje (y sus anexos) es privado, confidencial y 
> de exclusivo uso para el destinatario referenciado; es de público 
> conocimiento que las comunicaciones por medio de Internet no permiten 
> asegurar ni garantizar la confidencialidad de los mensajes transmitidos, así 
> como tampoco su integridad o su correcta recepción; es por ello que SOFSE no 
> se responsabiliza de posibles perjuicios derivados de la captura, 
> incorporaciones de virus o cualquier otra manipulación efectuada por 
> terceros. Las opiniones expresadas en este mensaje y en los archivos adjuntos 
> son propias del remitente y no representan la opinión o políticas de SOFSE, 
> salvo que se diga expresamente y el remitente se encuentre autorizado para 
> ello”
> “El contenido del presente mensaje (y sus anexos) es privado, confidencial y 
> de exclusivo uso para el 

Re: Consulta pgbouncer

[Romero, Fernando]

Hola, gracias por tu respuesta.

Esa parte ya la tengo, pero me da error

[postgres@postgres4 ~]$ cat /etc/pgbouncer/pgbouncer.database.ini
[databases]
appdb-rw= host=postgres1 dbname=appdb port=6434
[postgres@postgres4 ~]$ psql 'host=localhost dbname=appdb user=appdb 
password=appdb  port=6432'
psql: error: FATAL:  no such database: appdb
[postgres@postgres4 ~]$

?No encuentra la base



De: Hellmuth Vargas 
Enviado: domingo, 11 de septiembre de 2022 02:11 p.m.
Para: Romero, Fernando
Cc: Lista Postgres ES
Asunto: Re: Consulta pgbouncer

Hola

Le hace falta la sesión Database

https://www.pgbouncer.org/config.html#section-databases


El sáb., 10 de septiembre de 2022 1:58 p. m., Romero, Fernando 
mailto:fernando.rom...@trenesargentinos.gob.ar>>
 escribió:

Hola como estan, estoy configurando pgbouncer en un nodo testigo pero no logro 
conectarme

Esta es la conf del pgbouncer


[pgbouncer]

logfile = /var/log/pgbouncer/pgbouncer.log
pidfile = /var/run/pgbouncer/pgbouncer.pid

listen_addr = *
listen_port = 6432
unix_socket_dir = /tmp

auth_type = trust
auth_file = /etc/pgbouncer/userlist.txt
auth_hba_file = /etc/pgbouncer/pg_hba.conf

admin_users = postgres
stats_users = postgres

pool_mode = transaction
server_reset_query = DISCARD ALL

max_client_conn = 100
default_pool_size = 20
min_pool_size = 5
reserve_pool_size = 5
reserve_pool_timeout = 3

log_connections = 1
log_disconnections = 1
log_pooler_errors = 1

Tengo creada la base de datos pero no logro conectarme me tira este error:

[postgres@postgres4 ~]$ psql 'host=192.168.0.55 dbname=appdb user=appdb 
password=appdb  port=6432'
psql: error: FATAL:  no such database: appdb

La ip es del servidor que esta el pgbouncer base de datos existe y el usuario 
tambien
postgres=# \l
Listado de base de datos
  Nombre   |  Dueño   | Codificación |   Collate   |Ctype|  
Privilegios
---+--+--+-+-+---
 appdb | appdb| UTF8 | es_AR.UTF-8 | es_AR.UTF-8 |
 postgres  | postgres | UTF8 | es_AR.UTF-8 | es_AR.UTF-8 |
 repmgr| repmgr   | UTF8 | es_AR.UTF-8 | es_AR.UTF-8 |
 template0 | postgres | UTF8 | es_AR.UTF-8 | es_AR.UTF-8 | =c/postgres  
+
   |  |  | | | 
postgres=CTc/postgres
 template1 | postgres | UTF8 | es_AR.UTF-8 | es_AR.UTF-8 | =c/postgres  
+
   |  |  | | | 
postgres=CTc/postgres
(5 filas)

?En el pg_hba.conf tengo la linea para que permita la conexion
hostappdb   appdb192.168.0.0/24 trust

Y en el pg_hba.conf del pgbouncer
host pgbouncer pgbouncer 192.168.0.0/24 trust

Saludos?






"El contenido del presente mensaje (y sus anexos) es privado, confidencial y de 
exclusivo uso para el destinatario referenciado; es de público conocimiento que 
las comunicaciones por medio de Internet no permiten asegurar ni garantizar la 
confidencialidad de los mensajes transmitidos, así como tampoco su integridad o 
su correcta recepción; es por ello que SOFSE no se responsabiliza de posibles 
perjuicios derivados de la captura, incorporaciones de virus o cualquier otra 
manipulación efectuada por terceros. Las opiniones expresadas en este mensaje y 
en los archivos adjuntos son propias del remitente y no representan la opinión 
o políticas de SOFSE, salvo que se diga expresamente y el remitente se 
encuentre autorizado para ello"
"El contenido del presente mensaje (y sus anexos) es privado, confidencial y de 
exclusivo uso para el destinatario referenciado; es de público conocimiento que 
las comunicaciones por medio de Internet no permiten asegurar ni garantizar la 
confidencialidad de los mensajes transmitidos, así como tampoco su integridad o 
su correcta recepción; es por ello que SOFSE no se responsabiliza de posibles 
perjuicios derivados de la captura, incorporaciones de virus o cualquier otra 
manipulación efectuada por terceros. Las opiniones expresadas en este mensaje y 
en los archivos adjuntos son propias del remitente y no representan la opinión 
o políticas de SOFSE, salvo que se diga expresamente y el remitente se 
encuentre autorizado para ello"

Re: Consulta pgbouncer

[Hellmuth Vargas]

Hola

Le hace falta la sesión Database

https://www.pgbouncer.org/config.html#section-databases


El sáb., 10 de septiembre de 2022 1:58 p. m., Romero, Fernando <
fernando.rom...@trenesargentinos.gob.ar> escribió:

> Hola como estan, estoy configurando pgbouncer en un nodo testigo pero no
> logro conectarme
>
> Esta es la conf del pgbouncer
>
>
> [pgbouncer]
>
> logfile = /var/log/pgbouncer/pgbouncer.log
> pidfile = /var/run/pgbouncer/pgbouncer.pid
>
> listen_addr = *
> listen_port = 6432
> unix_socket_dir = /tmp
>
> auth_type = trust
> auth_file = /etc/pgbouncer/userlist.txt
> auth_hba_file = /etc/pgbouncer/pg_hba.conf
>
> admin_users = postgres
> stats_users = postgres
>
> pool_mode = transaction
> server_reset_query = DISCARD ALL
>
> max_client_conn = 100
> default_pool_size = 20
> min_pool_size = 5
> reserve_pool_size = 5
> reserve_pool_timeout = 3
>
> log_connections = 1
> log_disconnections = 1
> log_pooler_errors = 1
>
> Tengo creada la base de datos pero no logro conectarme me tira este error:
>
> [postgres@postgres4 ~]$ psql 'host=192.168.0.55 dbname=appdb user=appdb
> password=appdb  port=6432'
> psql: error: FATAL:  no such database: appdb
>
> La ip es del servidor que esta el pgbouncer base de datos existe y el
> usuario tambien
> postgres=# \l
> Listado de base de datos
>   Nombre   |  Dueño   | Codificación |   Collate   |Ctype|
> Privilegios
>
> ---+--+--+-+-+---
>  appdb | appdb| UTF8 | es_AR.UTF-8 | es_AR.UTF-8 |
>  postgres  | postgres | UTF8 | es_AR.UTF-8 | es_AR.UTF-8 |
>  repmgr| repmgr   | UTF8 | es_AR.UTF-8 | es_AR.UTF-8 |
>  template0 | postgres | UTF8 | es_AR.UTF-8 | es_AR.UTF-8 |
> =c/postgres  +
>|  |  | | |
> postgres=CTc/postgres
>  template1 | postgres | UTF8 | es_AR.UTF-8 | es_AR.UTF-8 |
> =c/postgres  +
>|  |  | | |
> postgres=CTc/postgres
> (5 filas)
>
> ​En el pg_hba.conf tengo la linea para que permita la conexion
> hostappdb   appdb192.168.0.0/24 trust
>
> Y en el pg_hba.conf del pgbouncer
> host pgbouncer pgbouncer 192.168.0.0/24 trust
>
> Saludos​
>
>
>
>
>
> “El contenido del presente mensaje (y sus anexos) es privado, confidencial
> y de exclusivo uso para el destinatario referenciado; es de público
> conocimiento que las comunicaciones por medio de Internet no permiten
> asegurar ni garantizar la confidencialidad de los mensajes transmitidos,
> así como tampoco su integridad o su correcta recepción; es por ello que
> SOFSE no se responsabiliza de posibles perjuicios derivados de la captura,
> incorporaciones de virus o cualquier otra manipulación efectuada por
> terceros. Las opiniones expresadas en este mensaje y en los archivos
> adjuntos son propias del remitente y no representan la opinión o políticas
> de SOFSE, salvo que se diga expresamente y el remitente se encuentre
> autorizado para ello”
>

Consulta pgbouncer

[Romero, Fernando]

Hola como estan, estoy configurando pgbouncer en un nodo testigo pero no logro 
conectarme

Esta es la conf del pgbouncer


[pgbouncer]

logfile = /var/log/pgbouncer/pgbouncer.log
pidfile = /var/run/pgbouncer/pgbouncer.pid

listen_addr = *
listen_port = 6432
unix_socket_dir = /tmp

auth_type = trust
auth_file = /etc/pgbouncer/userlist.txt
auth_hba_file = /etc/pgbouncer/pg_hba.conf

admin_users = postgres
stats_users = postgres

pool_mode = transaction
server_reset_query = DISCARD ALL

max_client_conn = 100
default_pool_size = 20
min_pool_size = 5
reserve_pool_size = 5
reserve_pool_timeout = 3

log_connections = 1
log_disconnections = 1
log_pooler_errors = 1

Tengo creada la base de datos pero no logro conectarme me tira este error:

[postgres@postgres4 ~]$ psql 'host=192.168.0.55 dbname=appdb user=appdb 
password=appdb  port=6432'
psql: error: FATAL:  no such database: appdb

La ip es del servidor que esta el pgbouncer base de datos existe y el usuario 
tambien
postgres=# \l
Listado de base de datos
  Nombre   |  Dueño   | Codificación |   Collate   |Ctype|  
Privilegios
---+--+--+-+-+---
 appdb | appdb| UTF8 | es_AR.UTF-8 | es_AR.UTF-8 |
 postgres  | postgres | UTF8 | es_AR.UTF-8 | es_AR.UTF-8 |
 repmgr| repmgr   | UTF8 | es_AR.UTF-8 | es_AR.UTF-8 |
 template0 | postgres | UTF8 | es_AR.UTF-8 | es_AR.UTF-8 | =c/postgres  
+
   |  |  | | | 
postgres=CTc/postgres
 template1 | postgres | UTF8 | es_AR.UTF-8 | es_AR.UTF-8 | =c/postgres  
+
   |  |  | | | 
postgres=CTc/postgres
(5 filas)

?En el pg_hba.conf tengo la linea para que permita la conexion
hostappdb   appdb192.168.0.0/24 trust

Y en el pg_hba.conf del pgbouncer
host pgbouncer pgbouncer 192.168.0.0/24 trust

Saludos?






"El contenido del presente mensaje (y sus anexos) es privado, confidencial y de 
exclusivo uso para el destinatario referenciado; es de público conocimiento que 
las comunicaciones por medio de Internet no permiten asegurar ni garantizar la 
confidencialidad de los mensajes transmitidos, así como tampoco su integridad o 
su correcta recepción; es por ello que SOFSE no se responsabiliza de posibles 
perjuicios derivados de la captura, incorporaciones de virus o cualquier otra 
manipulación efectuada por terceros. Las opiniones expresadas en este mensaje y 
en los archivos adjuntos son propias del remitente y no representan la opinión 
o políticas de SOFSE, salvo que se diga expresamente y el remitente se 
encuentre autorizado para ello"

Re: Consulta conexión y puerto

[Juan]

Tenés razon

El vie., 2 de septiembre de 2022 00:16, Horacio Miranda 
escribió:

> @juan hay una foto de la iptables -L
> El problema como lo veo eran 2.
> 1: Apuntaba a una IP equivocada.
> 2: pg_hba.conf tenia 192.168.0.0/32 cuando debia ser 192.168.0.0/24 o
> 192.168.0.0/16 dependiendo de la red que usan.
>
>
> On 2/09/2022, at 2:26 PM, Juan  wrote:
>
> Hola,
>
> Que te dice iptables -L
>
> On Thu, Sep 1, 2022 at 6:51 PM Romero, Fernando <
> fernando.rom...@trenesargentinos.gob.ar> wrote:
>
>> Hola Horacio gracias por tu respuesta.
>>
>> Sigo con el problema, el selinux ya lo tengo deshabilitado pero sigo sin
>> ver el puerto desde la red
>>
>> Lo del postgresql.conf lo tengo tal como pones, no se si tengo que
>> cambiar el targeted en el selinux
>>
>> 
>>
>>
>> Asi tengo el pg_hba.conf, habilite toda la red para las pruebas
>>
>>
>> 
>>
>> Cuando escaneo los puertos del servidor que me quiero conectar no me
>> muestra el de postgres
>>
>> 
>>
>>
>> El netstat me trae esto
>>
>> 
>>
>> Pero cuando me quiero conectar me da este error:
>>
>>
>> ​
>>
>> ​
>> --
>> *De:* Horacio Miranda 
>> *Enviado:* jueves, 01 de septiembre de 2022 06:18 p.m.
>> *Para:* Romero, Fernando
>> *Cc:* pgsql-es-ay...@postgresql.org
>> *Asunto:* Re: Consulta conexión y puerto
>>
>>
>>
>> On 2/09/2022, at 5:20 AM, Romero, Fernando <
>> fernando.rom...@trenesargentinos.gob.ar> wrote:
>>
>> Hola como estan.
>>
>> Hola
>>
>> Tengo problema con las conexiones desde la red, a la base se conectan
>> desde la lan.
>> El tema que no veo el puerto 5432 desde los otros host de la red y si
>> miro lso puertos abiertos en el servidor
>> cuando hago un scaneo en el localhost me muestra el 5432 pero si lo hago
>> sobre la ip ya no me lo muestra
>>
>> Por defecto postgresql tiene un linea en el postgresql.conf
>> listen_addresses = 'localhost’
>>
>> Cambialo por
>> listen_addresses = ‘*’
>> Esto abre el puerto en el localhost y en las interfaces o puedes poner la
>> IP de la tarjeta  o puedes poner una lista separada por comas.
>>
>> el archivo pg_hba.conf maneja los accesos.
>>
>> asegurate que el archivo que estas editando sea el correcto, revisa el
>> PID del proceso que tiene el puerto 5432
>>
>> lsof -p 
>>
>> te dice los open files del PID del postgresql.
>>
>> netstat -nap | grep 5432 ( te da mas información ).
>>
>> si estas usando postgresql como RPM en centos/redhat deberia estar con
>> las reglas selinux OK.
>>
>> rpm -V $(rpm -qa | grep postgresql) debiera verificar todos los
>> contenidos que no hayan sido cambiados.
>>
>> Espero que esto te ayude.
>>
>> ​
>>
>> Tengo habilitado el puerto y el listen en el postgresql.conf para todos
>> los host
>> Que me esta faltando?
>>
>> Saludos
>> “El contenido del presente mensaje (y sus anexos) es privado,
>> confidencial y de exclusivo uso para el destinatario referenciado; es de
>> público conocimiento que las comunicaciones por medio de Internet
>> no permiten asegurar ni garantizar la confidencialidad de los mensajes
>> transmitidos, así como tampoco su integridad o su correcta recepción; es
>> por ello que SOFSE no se responsabiliza de posibles perjuicios derivados de
>> la captura, incorporaciones de virus o cualquier otra manipulación
>> efectuada por terceros. Las opiniones expresadas en este mensaje y en los
>> archivos adjuntos son propias del remitente y no representan la opinión o
>> políticas de SOFSE, salvo que se diga expresamente y el remitente se
>> encuentre autorizado para ello”
>>
>>
>> “El contenido del presente mensaje (y sus anexos) es privado,
>> confidencial y de exclusivo uso para el destinatario referenciado; es de
>> público conocimiento que las comunicaciones por medio de Internet no
>> permiten asegurar ni garantizar la confidencialidad de los mensajes
>> transmitidos, así como tampoco su integridad o su correcta recepción; es
>> por ello que SOFSE no se responsabiliza de posibles perjuicios derivados de
>> la captura, incorporaciones de virus o cualquier otra manipulación
>> efectuada por terceros. Las opiniones expresadas en este mensaje y en los
>> archivos adjuntos son propias del remitente y no representan la opinión o
>> políticas de SOFSE, salvo que se diga expresamente y el remitente se
>> encuentre autorizado para ello”
>>
>
>

Re: Consulta conexión y puerto

[Horacio Miranda]

@juan hay una foto de la iptables -L 
El problema como lo veo eran 2.
1: Apuntaba a una IP equivocada.
2: pg_hba.conf tenia 192.168.0.0/32 cuando debia ser 192.168.0.0/24 o 
192.168.0.0/16 dependiendo de la red que usan.


> On 2/09/2022, at 2:26 PM, Juan  wrote:
> 
> Hola, 
> 
> Que te dice iptables -L
> 
> On Thu, Sep 1, 2022 at 6:51 PM Romero, Fernando 
>  <mailto:fernando.rom...@trenesargentinos.gob.ar>> wrote:
> Hola Horacio gracias por tu respuesta.
> 
> Sigo con el problema, el selinux ya lo tengo deshabilitado pero sigo sin ver 
> el puerto desde la red
> 
> Lo del postgresql.conf lo tengo tal como pones, no se si tengo que cambiar el 
> targeted en el selinux
> 
> 
> 
> 
> 
> Asi tengo el pg_hba.conf, habilite toda la red para las pruebas
> 
> 
> 
> 
> 
> Cuando escaneo los puertos del servidor que me quiero conectar no me muestra 
> el de postgres
> 
> 
> 
> 
> 
> El netstat me trae esto
> 
> 
> 
> Pero cuando me quiero conectar me da este error:
> 
> 
> 
> ​
> 
> ​
> 
> De: Horacio Miranda mailto:hmira...@gmail.com>>
> Enviado: jueves, 01 de septiembre de 2022 06:18 p.m.
> Para: Romero, Fernando
> Cc: pgsql-es-ay...@postgresql.org <mailto:pgsql-es-ay...@postgresql.org>
> Asunto: Re: Consulta conexión y puerto
>  
> 
> 
>> On 2/09/2022, at 5:20 AM, Romero, Fernando 
>> > <mailto:fernando.rom...@trenesargentinos.gob.ar>> wrote:
>> 
>> Hola como estan.
> Hola
>> Tengo problema con las conexiones desde la red, a la base se conectan desde 
>> la lan.
>> El tema que no veo el puerto 5432 desde los otros host de la red y si miro 
>> lso puertos abiertos en el servidor
>> cuando hago un scaneo en el localhost me muestra el 5432 pero si lo hago 
>> sobre la ip ya no me lo muestra
>> 
> Por defecto postgresql tiene un linea en el postgresql.conf
> listen_addresses = 'localhost’ 
> 
> Cambialo por
> listen_addresses = ‘*’ 
> Esto abre el puerto en el localhost y en las interfaces o puedes poner la IP 
> de la tarjeta  o puedes poner una lista separada por comas.
> 
> el archivo pg_hba.conf maneja los accesos.
> 
> asegurate que el archivo que estas editando sea el correcto, revisa el PID 
> del proceso que tiene el puerto 5432
> 
> lsof -p 
> 
> te dice los open files del PID del postgresql.
> 
> netstat -nap | grep 5432 ( te da mas información ). 
> 
> si estas usando postgresql como RPM en centos/redhat deberia estar con las 
> reglas selinux OK.
> 
> rpm -V $(rpm -qa | grep postgresql) debiera verificar todos los contenidos 
> que no hayan sido cambiados.
> 
> Espero que esto te ayude. 
> 
>> ​
>> 
>> Tengo habilitado el puerto y el listen en el postgresql.conf para todos los 
>> host
>> Que me esta faltando?
>> 
>> Saludos
>> “El contenido del presente mensaje (y sus anexos) es privado, confidencial y 
>> de exclusivo uso para el destinatario referenciado; es de público 
>> conocimiento que las comunicaciones por medio de Internet no permiten 
>> asegurar ni garantizar la confidencialidad de los mensajes transmitidos, así 
>> como tampoco su integridad o su correcta recepción; es por ello que SOFSE no 
>> se responsabiliza de posibles perjuicios derivados de la captura, 
>> incorporaciones de virus o cualquier otra manipulación efectuada por 
>> terceros. Las opiniones expresadas en este mensaje y en los archivos 
>> adjuntos son propias del remitente y no representan la opinión o políticas 
>> de SOFSE, salvo que se diga expresamente y el remitente se encuentre 
>> autorizado para ello”
> 
> “El contenido del presente mensaje (y sus anexos) es privado, confidencial y 
> de exclusivo uso para el destinatario referenciado; es de público 
> conocimiento que las comunicaciones por medio de Internet no permiten 
> asegurar ni garantizar la confidencialidad de los mensajes transmitidos, así 
> como tampoco su integridad o su correcta recepción; es por ello que SOFSE no 
> se responsabiliza de posibles perjuicios derivados de la captura, 
> incorporaciones de virus o cualquier otra manipulación efectuada por 
> terceros. Las opiniones expresadas en este mensaje y en los archivos adjuntos 
> son propias del remitente y no representan la opinión o políticas de SOFSE, 
> salvo que se diga expresamente y el remitente se encuentre autorizado para 
> ello”

Re: Consulta conexión y puerto

[Horacio Miranda]

Y creo que estabas apuntando a un IP incorrecta ? 

> On 2/09/2022, at 12:45 PM, Romero, Fernando 
>  wrote:
> 
> ​Estaba definiendo mal la red, para toda la red era /24 y /32
> Saludos
> De: Horacio Miranda mailto:hmira...@gmail.com>>
> Enviado: jueves, 01 de septiembre de 2022 08:19 p.m.
> Para: Romero, Fernando
> Cc: pgsql-es-ay...@postgresql.org
> Asunto: Re: Consulta conexión y puerto
>  
> Entonces para resumir. 
> el IP que estabas usando era el incorrecto ? 
> la entrada en el pg_hba.conf tenia /32 cuando debia ser /24 o /16 
> eso era el problema que tenias ? 
> 
>> On 2/09/2022, at 10:25 AM, Romero, Fernando 
>> > <mailto:fernando.rom...@trenesargentinos.gob.ar>> wrote:
>> 
>> ​Ya encontre el error, gracias!
>> De: Horacio Miranda mailto:hmira...@gmail.com>>
>> Enviado: jueves, 01 de septiembre de 2022 06:55 p.m.
>> Para: Romero, Fernando
>> Cc: pgsql-es-ay...@postgresql.org <mailto:pgsql-es-ay...@postgresql.org>
>> Asunto: Re: Consulta conexión y puerto
>>  
>> Veo el puerto abierto para todas partes.
>> 
>> ifconfig 
>> para ver las IP de la maquina.
>> 
>> grep -i -R listen_addresses /var/lib/pgsql/
>> 
>> iptables -L 
>> 
>> puede que sea reglas de firewall. 
>> 
>>> On 2/09/2022, at 9:51 AM, Romero, Fernando 
>>> >> <mailto:fernando.rom...@trenesargentinos.gob.ar>> wrote:
>>> 
>>> Hola Horacio gracias por tu respuesta.
>>> Sigo con el problema, el selinux ya lo tengo deshabilitado pero sigo sin 
>>> ver el puerto desde la red
>>> Lo del postgresql.conf lo tengo tal como pones, no se si tengo que cambiar 
>>> el targeted en el selinux
>>> 
>>> 
>>> Asi tengo el pg_hba.conf, habilite toda la red para las pruebas
>>> 
>>> 
>>> Cuando escaneo los puertos del servidor que me quiero conectar no me 
>>> muestra el de postgres
>>> 
>>> 
>>> El netstat me trae esto
>>> 
>>> Pero cuando me quiero conectar me da este error:
>>> 
>>> ​
>>> ​
>>> De: Horacio Miranda mailto:hmira...@gmail.com>>
>>> Enviado: jueves, 01 de septiembre de 2022 06:18 p.m.
>>> Para: Romero, Fernando
>>> Cc: pgsql-es-ay...@postgresql.org <mailto:pgsql-es-ay...@postgresql.org>
>>> Asunto: Re: Consulta conexión y puerto
>>>  
>>> 
>>> 
>>>> On 2/09/2022, at 5:20 AM, Romero, Fernando 
>>>> >>> <mailto:fernando.rom...@trenesargentinos.gob.ar>> wrote:
>>>> 
>>>> Hola como estan.
>>> Hola
>>>> Tengo problema con las conexiones desde la red, a la base se conectan 
>>>> desde la lan.
>>>> El tema que no veo el puerto 5432 desde los otros host de la red y si miro 
>>>> lso puertos abiertos en el servidor
>>>> cuando hago un scaneo en el localhost me muestra el 5432 pero si lo hago 
>>>> sobre la ip ya no me lo muestra
>>>> 
>>> Por defecto postgresql tiene un linea en el postgresql.conf
>>> listen_addresses = 'localhost’ 
>>> 
>>> Cambialo por
>>> listen_addresses = ‘*’ 
>>> Esto abre el puerto en el localhost y en las interfaces o puedes poner la 
>>> IP de la tarjeta  o puedes poner una lista separada por comas.
>>> 
>>> el archivo pg_hba.conf maneja los accesos.
>>> 
>>> asegurate que el archivo que estas editando sea el correcto, revisa el PID 
>>> del proceso que tiene el puerto 5432
>>> 
>>> lsof -p 
>>> 
>>> te dice los open files del PID del postgresql.
>>> 
>>> netstat -nap | grep 5432 ( te da mas información ). 
>>> 
>>> si estas usando postgresql como RPM en centos/redhat deberia estar con las 
>>> reglas selinux OK.
>>> 
>>> rpm -V $(rpm -qa | grep postgresql) debiera verificar todos los contenidos 
>>> que no hayan sido cambiados.
>>> 
>>> Espero que esto te ayude. 
>>> 
>>>> ​
>>>> 
>>>> Tengo habilitado el puerto y el listen en el postgresql.conf para todos 
>>>> los host
>>>> Que me esta faltando?
>>>> 
>>>> Saludos
>>>> “El contenido del presente mensaje (y sus anexos) es privado, confidencial 
>>>> y de exclusivo uso para el destinatario referenciado; es de público 
>>>> conocimiento que las comunicaciones por medio de Internet no permiten 
>>>> asegurar ni garantizar la confidencialidad de lo

Re: Consulta conexión y puerto

[Romero, Fernando]

​Estaba definiendo mal la red, para toda la red era /24 y /32

Saludos


De: Horacio Miranda 
Enviado: jueves, 01 de septiembre de 2022 08:19 p.m.
Para: Romero, Fernando
Cc: pgsql-es-ay...@postgresql.org
Asunto: Re: Consulta conexión y puerto

Entonces para resumir.
el IP que estabas usando era el incorrecto ?
la entrada en el pg_hba.conf tenia /32 cuando debia ser /24 o /16
eso era el problema que tenias ?

On 2/09/2022, at 10:25 AM, Romero, Fernando 
mailto:fernando.rom...@trenesargentinos.gob.ar>>
 wrote:

​Ya encontre el error, gracias!

De: Horacio Miranda mailto:hmira...@gmail.com>>
Enviado: jueves, 01 de septiembre de 2022 06:55 p.m.
Para: Romero, Fernando
Cc: pgsql-es-ay...@postgresql.org<mailto:pgsql-es-ay...@postgresql.org>
Asunto: Re: Consulta conexión y puerto

Veo el puerto abierto para todas partes.

ifconfig
para ver las IP de la maquina.

grep -i -R listen_addresses /var/lib/pgsql/

iptables -L

puede que sea reglas de firewall.

On 2/09/2022, at 9:51 AM, Romero, Fernando 
mailto:fernando.rom...@trenesargentinos.gob.ar>>
 wrote:

Hola Horacio gracias por tu respuesta.
Sigo con el problema, el selinux ya lo tengo deshabilitado pero sigo sin ver el 
puerto desde la red
Lo del postgresql.conf lo tengo tal como pones, no se si tengo que cambiar el 
targeted en el selinux


Asi tengo el pg_hba.conf, habilite toda la red para las pruebas


Cuando escaneo los puertos del servidor que me quiero conectar no me muestra el 
de postgres


El netstat me trae esto

Pero cuando me quiero conectar me da este error:

​
​

De: Horacio Miranda mailto:hmira...@gmail.com>>
Enviado: jueves, 01 de septiembre de 2022 06:18 p.m.
Para: Romero, Fernando
Cc: pgsql-es-ay...@postgresql.org<mailto:pgsql-es-ay...@postgresql.org>
Asunto: Re: Consulta conexión y puerto



On 2/09/2022, at 5:20 AM, Romero, Fernando 
mailto:fernando.rom...@trenesargentinos.gob.ar>>
 wrote:

Hola como estan.
Hola
Tengo problema con las conexiones desde la red, a la base se conectan desde la 
lan.
El tema que no veo el puerto 5432 desde los otros host de la red y si miro lso 
puertos abiertos en el servidor
cuando hago un scaneo en el localhost me muestra el 5432 pero si lo hago sobre 
la ip ya no me lo muestra

Por defecto postgresql tiene un linea en el postgresql.conf
listen_addresses = 'localhost’

Cambialo por
listen_addresses = ‘*’
Esto abre el puerto en el localhost y en las interfaces o puedes poner la IP de 
la tarjeta  o puedes poner una lista separada por comas.

el archivo pg_hba.conf maneja los accesos.

asegurate que el archivo que estas editando sea el correcto, revisa el PID del 
proceso que tiene el puerto 5432

lsof -p 

te dice los open files del PID del postgresql.

netstat -nap | grep 5432 ( te da mas información ).

si estas usando postgresql como RPM en centos/redhat deberia estar con las 
reglas selinux OK.

rpm -V $(rpm -qa | grep postgresql) debiera verificar todos los contenidos que 
no hayan sido cambiados.

Espero que esto te ayude.

​

Tengo habilitado el puerto y el listen en el postgresql.conf para todos los host
Que me esta faltando?

Saludos
“El contenido del presente mensaje (y sus anexos) es privado, confidencial y de 
exclusivo uso para el destinatario referenciado; es de público conocimiento que 
las comunicaciones por medio de Internet no permiten asegurar ni garantizar la 
confidencialidad de los mensajes transmitidos, así como tampoco su integridad o 
su correcta recepción; es por ello que SOFSE no se responsabiliza de posibles 
perjuicios derivados de la captura, incorporaciones de virus o cualquier otra 
manipulación efectuada por terceros. Las opiniones expresadas en este mensaje y 
en los archivos adjuntos son propias del remitente y no representan la opinión 
o políticas de SOFSE, salvo que se diga expresamente y el remitente se 
encuentre autorizado para ello”

“El contenido del presente mensaje (y sus anexos) es privado, confidencial y de 
exclusivo uso para el destinatario referenciado; es de público conocimiento que 
las comunicaciones por medio de Internet no permiten asegurar ni garantizar la 
confidencialidad de los mensajes transmitidos, así como tampoco su integridad o 
su correcta recepción; es por ello que SOFSE no se responsabiliza de posibles 
perjuicios derivados de la captura, incorporaciones de virus o cualquier otra 
manipulación efectuada por terceros. Las opiniones expresadas en este mensaje y 
en los archivos adjuntos son propias del remitente y no representan la opinión 
o políticas de SOFSE, salvo que se diga expresamente y el remitente se 
encuentre autorizado para ello”

“El contenido del presente mensaje (y sus anexos) es privado, confidencial y de 
exclusivo uso para el destinatario referenciado; es de público conocimiento que 
las comunicaciones por medio de Internet no permiten asegurar ni garantizar la 
confidencialidad de los 

Re: Consulta conexión y puerto

[Horacio Miranda]

Entonces para resumir. 
el IP que estabas usando era el incorrecto ? 
la entrada en el pg_hba.conf tenia /32 cuando debia ser /24 o /16 
eso era el problema que tenias ? 

> On 2/09/2022, at 10:25 AM, Romero, Fernando 
>  wrote:
> 
> ​Ya encontre el error, gracias!
> De: Horacio Miranda mailto:hmira...@gmail.com>>
> Enviado: jueves, 01 de septiembre de 2022 06:55 p.m.
> Para: Romero, Fernando
> Cc: pgsql-es-ay...@postgresql.org
> Asunto: Re: Consulta conexión y puerto
>  
> Veo el puerto abierto para todas partes.
> 
> ifconfig 
> para ver las IP de la maquina.
> 
> grep -i -R listen_addresses /var/lib/pgsql/
> 
> iptables -L 
> 
> puede que sea reglas de firewall. 
> 
>> On 2/09/2022, at 9:51 AM, Romero, Fernando 
>> > <mailto:fernando.rom...@trenesargentinos.gob.ar>> wrote:
>> 
>> Hola Horacio gracias por tu respuesta.
>> Sigo con el problema, el selinux ya lo tengo deshabilitado pero sigo sin ver 
>> el puerto desde la red
>> Lo del postgresql.conf lo tengo tal como pones, no se si tengo que cambiar 
>> el targeted en el selinux
>> 
>> 
>> Asi tengo el pg_hba.conf, habilite toda la red para las pruebas
>> 
>> 
>> Cuando escaneo los puertos del servidor que me quiero conectar no me muestra 
>> el de postgres
>> 
>> 
>> El netstat me trae esto
>> 
>> Pero cuando me quiero conectar me da este error:
>> 
>> ​
>> ​
>> De: Horacio Miranda mailto:hmira...@gmail.com>>
>> Enviado: jueves, 01 de septiembre de 2022 06:18 p.m.
>> Para: Romero, Fernando
>> Cc: pgsql-es-ay...@postgresql.org <mailto:pgsql-es-ay...@postgresql.org>
>> Asunto: Re: Consulta conexión y puerto
>>  
>> 
>> 
>>> On 2/09/2022, at 5:20 AM, Romero, Fernando 
>>> >> <mailto:fernando.rom...@trenesargentinos.gob.ar>> wrote:
>>> 
>>> Hola como estan.
>> Hola
>>> Tengo problema con las conexiones desde la red, a la base se conectan desde 
>>> la lan.
>>> El tema que no veo el puerto 5432 desde los otros host de la red y si miro 
>>> lso puertos abiertos en el servidor
>>> cuando hago un scaneo en el localhost me muestra el 5432 pero si lo hago 
>>> sobre la ip ya no me lo muestra
>>> 
>> Por defecto postgresql tiene un linea en el postgresql.conf
>> listen_addresses = 'localhost’ 
>> 
>> Cambialo por
>> listen_addresses = ‘*’ 
>> Esto abre el puerto en el localhost y en las interfaces o puedes poner la IP 
>> de la tarjeta  o puedes poner una lista separada por comas.
>> 
>> el archivo pg_hba.conf maneja los accesos.
>> 
>> asegurate que el archivo que estas editando sea el correcto, revisa el PID 
>> del proceso que tiene el puerto 5432
>> 
>> lsof -p 
>> 
>> te dice los open files del PID del postgresql.
>> 
>> netstat -nap | grep 5432 ( te da mas información ). 
>> 
>> si estas usando postgresql como RPM en centos/redhat deberia estar con las 
>> reglas selinux OK.
>> 
>> rpm -V $(rpm -qa | grep postgresql) debiera verificar todos los contenidos 
>> que no hayan sido cambiados.
>> 
>> Espero que esto te ayude. 
>> 
>>> ​
>>> 
>>> Tengo habilitado el puerto y el listen en el postgresql.conf para todos los 
>>> host
>>> Que me esta faltando?
>>> 
>>> Saludos
>>> “El contenido del presente mensaje (y sus anexos) es privado, confidencial 
>>> y de exclusivo uso para el destinatario referenciado; es de público 
>>> conocimiento que las comunicaciones por medio de Internet no permiten 
>>> asegurar ni garantizar la confidencialidad de los mensajes transmitidos, 
>>> así como tampoco su integridad o su correcta recepción; es por ello que 
>>> SOFSE no se responsabiliza de posibles perjuicios derivados de la captura, 
>>> incorporaciones de virus o cualquier otra manipulación efectuada por 
>>> terceros. Las opiniones expresadas en este mensaje y en los archivos 
>>> adjuntos son propias del remitente y no representan la opinión o políticas 
>>> de SOFSE, salvo que se diga expresamente y el remitente se encuentre 
>>> autorizado para ello”
>> 
>> “El contenido del presente mensaje (y sus anexos) es privado, confidencial y 
>> de exclusivo uso para el destinatario referenciado; es de público 
>> conocimiento que las comunicaciones por medio de Internet no permiten 
>> asegurar ni garantizar la confidencialidad de los mensajes transmitidos, así 
>> como tampoco su integridad o su correcta recepción; es por 

Re: Consulta conexión y puerto

[Romero, Fernando]

​Ya encontre el error, gracias!


De: Horacio Miranda 
Enviado: jueves, 01 de septiembre de 2022 06:55 p.m.
Para: Romero, Fernando
Cc: pgsql-es-ay...@postgresql.org
Asunto: Re: Consulta conexión y puerto

Veo el puerto abierto para todas partes.

ifconfig
para ver las IP de la maquina.

grep -i -R listen_addresses /var/lib/pgsql/

iptables -L

puede que sea reglas de firewall.

On 2/09/2022, at 9:51 AM, Romero, Fernando 
mailto:fernando.rom...@trenesargentinos.gob.ar>>
 wrote:

Hola Horacio gracias por tu respuesta.
Sigo con el problema, el selinux ya lo tengo deshabilitado pero sigo sin ver el 
puerto desde la red
Lo del postgresql.conf lo tengo tal como pones, no se si tengo que cambiar el 
targeted en el selinux


Asi tengo el pg_hba.conf, habilite toda la red para las pruebas


Cuando escaneo los puertos del servidor que me quiero conectar no me muestra el 
de postgres


El netstat me trae esto

Pero cuando me quiero conectar me da este error:

​
​

De: Horacio Miranda mailto:hmira...@gmail.com>>
Enviado: jueves, 01 de septiembre de 2022 06:18 p.m.
Para: Romero, Fernando
Cc: pgsql-es-ay...@postgresql.org<mailto:pgsql-es-ay...@postgresql.org>
Asunto: Re: Consulta conexión y puerto



On 2/09/2022, at 5:20 AM, Romero, Fernando 
mailto:fernando.rom...@trenesargentinos.gob.ar>>
 wrote:

Hola como estan.
Hola
Tengo problema con las conexiones desde la red, a la base se conectan desde la 
lan.
El tema que no veo el puerto 5432 desde los otros host de la red y si miro lso 
puertos abiertos en el servidor
cuando hago un scaneo en el localhost me muestra el 5432 pero si lo hago sobre 
la ip ya no me lo muestra

Por defecto postgresql tiene un linea en el postgresql.conf
listen_addresses = 'localhost’

Cambialo por
listen_addresses = ‘*’
Esto abre el puerto en el localhost y en las interfaces o puedes poner la IP de 
la tarjeta  o puedes poner una lista separada por comas.

el archivo pg_hba.conf maneja los accesos.

asegurate que el archivo que estas editando sea el correcto, revisa el PID del 
proceso que tiene el puerto 5432

lsof -p 

te dice los open files del PID del postgresql.

netstat -nap | grep 5432 ( te da mas información ).

si estas usando postgresql como RPM en centos/redhat deberia estar con las 
reglas selinux OK.

rpm -V $(rpm -qa | grep postgresql) debiera verificar todos los contenidos que 
no hayan sido cambiados.

Espero que esto te ayude.

​

Tengo habilitado el puerto y el listen en el postgresql.conf para todos los host
Que me esta faltando?

Saludos
“El contenido del presente mensaje (y sus anexos) es privado, confidencial y de 
exclusivo uso para el destinatario referenciado; es de público conocimiento que 
las comunicaciones por medio de Internet no permiten asegurar ni garantizar la 
confidencialidad de los mensajes transmitidos, así como tampoco su integridad o 
su correcta recepción; es por ello que SOFSE no se responsabiliza de posibles 
perjuicios derivados de la captura, incorporaciones de virus o cualquier otra 
manipulación efectuada por terceros. Las opiniones expresadas en este mensaje y 
en los archivos adjuntos son propias del remitente y no representan la opinión 
o políticas de SOFSE, salvo que se diga expresamente y el remitente se 
encuentre autorizado para ello”

“El contenido del presente mensaje (y sus anexos) es privado, confidencial y de 
exclusivo uso para el destinatario referenciado; es de público conocimiento que 
las comunicaciones por medio de Internet no permiten asegurar ni garantizar la 
confidencialidad de los mensajes transmitidos, así como tampoco su integridad o 
su correcta recepción; es por ello que SOFSE no se responsabiliza de posibles 
perjuicios derivados de la captura, incorporaciones de virus o cualquier otra 
manipulación efectuada por terceros. Las opiniones expresadas en este mensaje y 
en los archivos adjuntos son propias del remitente y no representan la opinión 
o políticas de SOFSE, salvo que se diga expresamente y el remitente se 
encuentre autorizado para ello”

“El contenido del presente mensaje (y sus anexos) es privado, confidencial y de 
exclusivo uso para el destinatario referenciado; es de público conocimiento que 
las comunicaciones por medio de Internet no permiten asegurar ni garantizar la 
confidencialidad de los mensajes transmitidos, así como tampoco su integridad o 
su correcta recepción; es por ello que SOFSE no se responsabiliza de posibles 
perjuicios derivados de la captura, incorporaciones de virus o cualquier otra 
manipulación efectuada por terceros. Las opiniones expresadas en este mensaje y 
en los archivos adjuntos son propias del remitente y no representan la opinión 
o políticas de SOFSE, salvo que se diga expresamente y el remitente se 
encuentre autorizado para ello”

Re: Consulta conexión y puerto

[Romero, Fernando]

Ahora me tira otro error despues de reiniciar

psql: error: FATAL:  no hay una línea en pg_hba.conf para «192.168.0.246», 
usuario «repmgr», base de datos «repmgr», SSL inactivo

Esta linea de pg_hba.conf no habilita todo la red?
[cid:f733752b-f5d6-4136-b44f-cef5e91a2e37]​



De: Horacio Miranda 
Enviado: jueves, 01 de septiembre de 2022 06:55 p.m.
Para: Romero, Fernando
Cc: pgsql-es-ay...@postgresql.org
Asunto: Re: Consulta conexión y puerto

Veo el puerto abierto para todas partes.

ifconfig
para ver las IP de la maquina.

grep -i -R listen_addresses /var/lib/pgsql/

iptables -L

puede que sea reglas de firewall.

On 2/09/2022, at 9:51 AM, Romero, Fernando 
mailto:fernando.rom...@trenesargentinos.gob.ar>>
 wrote:

Hola Horacio gracias por tu respuesta.
Sigo con el problema, el selinux ya lo tengo deshabilitado pero sigo sin ver el 
puerto desde la red
Lo del postgresql.conf lo tengo tal como pones, no se si tengo que cambiar el 
targeted en el selinux


Asi tengo el pg_hba.conf, habilite toda la red para las pruebas


Cuando escaneo los puertos del servidor que me quiero conectar no me muestra el 
de postgres


El netstat me trae esto

Pero cuando me quiero conectar me da este error:

​
​

De: Horacio Miranda mailto:hmira...@gmail.com>>
Enviado: jueves, 01 de septiembre de 2022 06:18 p.m.
Para: Romero, Fernando
Cc: pgsql-es-ay...@postgresql.org<mailto:pgsql-es-ay...@postgresql.org>
Asunto: Re: Consulta conexión y puerto



On 2/09/2022, at 5:20 AM, Romero, Fernando 
mailto:fernando.rom...@trenesargentinos.gob.ar>>
 wrote:

Hola como estan.
Hola
Tengo problema con las conexiones desde la red, a la base se conectan desde la 
lan.
El tema que no veo el puerto 5432 desde los otros host de la red y si miro lso 
puertos abiertos en el servidor
cuando hago un scaneo en el localhost me muestra el 5432 pero si lo hago sobre 
la ip ya no me lo muestra

Por defecto postgresql tiene un linea en el postgresql.conf
listen_addresses = 'localhost’

Cambialo por
listen_addresses = ‘*’
Esto abre el puerto en el localhost y en las interfaces o puedes poner la IP de 
la tarjeta  o puedes poner una lista separada por comas.

el archivo pg_hba.conf maneja los accesos.

asegurate que el archivo que estas editando sea el correcto, revisa el PID del 
proceso que tiene el puerto 5432

lsof -p 

te dice los open files del PID del postgresql.

netstat -nap | grep 5432 ( te da mas información ).

si estas usando postgresql como RPM en centos/redhat deberia estar con las 
reglas selinux OK.

rpm -V $(rpm -qa | grep postgresql) debiera verificar todos los contenidos que 
no hayan sido cambiados.

Espero que esto te ayude.

​

Tengo habilitado el puerto y el listen en el postgresql.conf para todos los host
Que me esta faltando?

Saludos
“El contenido del presente mensaje (y sus anexos) es privado, confidencial y de 
exclusivo uso para el destinatario referenciado; es de público conocimiento que 
las comunicaciones por medio de Internet no permiten asegurar ni garantizar la 
confidencialidad de los mensajes transmitidos, así como tampoco su integridad o 
su correcta recepción; es por ello que SOFSE no se responsabiliza de posibles 
perjuicios derivados de la captura, incorporaciones de virus o cualquier otra 
manipulación efectuada por terceros. Las opiniones expresadas en este mensaje y 
en los archivos adjuntos son propias del remitente y no representan la opinión 
o políticas de SOFSE, salvo que se diga expresamente y el remitente se 
encuentre autorizado para ello”

“El contenido del presente mensaje (y sus anexos) es privado, confidencial y de 
exclusivo uso para el destinatario referenciado; es de público conocimiento que 
las comunicaciones por medio de Internet no permiten asegurar ni garantizar la 
confidencialidad de los mensajes transmitidos, así como tampoco su integridad o 
su correcta recepción; es por ello que SOFSE no se responsabiliza de posibles 
perjuicios derivados de la captura, incorporaciones de virus o cualquier otra 
manipulación efectuada por terceros. Las opiniones expresadas en este mensaje y 
en los archivos adjuntos son propias del remitente y no representan la opinión 
o políticas de SOFSE, salvo que se diga expresamente y el remitente se 
encuentre autorizado para ello”

“El contenido del presente mensaje (y sus anexos) es privado, confidencial y de 
exclusivo uso para el destinatario referenciado; es de público conocimiento que 
las comunicaciones por medio de Internet no permiten asegurar ni garantizar la 
confidencialidad de los mensajes transmitidos, así como tampoco su integridad o 
su correcta recepción; es por ello que SOFSE no se responsabiliza de posibles 
perjuicios derivados de la captura, incorporaciones de virus o cualquier otra 
manipulación efectuada por terceros. Las opiniones expresadas en este mensaje y 
en los archivos adjuntos son propias del remitente y no representan la opinión 
o políticas de 

Re: Consulta conexión y puerto

[Romero, Fernando]

No tengo fw

[cid:54ade1c7-c7ec-409a-a4ca-2ba37d91d34b]​


De: Horacio Miranda 
Enviado: jueves, 01 de septiembre de 2022 06:55 p.m.
Para: Romero, Fernando
Cc: pgsql-es-ay...@postgresql.org
Asunto: Re: Consulta conexión y puerto

Veo el puerto abierto para todas partes.

ifconfig
para ver las IP de la maquina.

grep -i -R listen_addresses /var/lib/pgsql/

iptables -L

puede que sea reglas de firewall.

On 2/09/2022, at 9:51 AM, Romero, Fernando 
mailto:fernando.rom...@trenesargentinos.gob.ar>>
 wrote:

Hola Horacio gracias por tu respuesta.
Sigo con el problema, el selinux ya lo tengo deshabilitado pero sigo sin ver el 
puerto desde la red
Lo del postgresql.conf lo tengo tal como pones, no se si tengo que cambiar el 
targeted en el selinux


Asi tengo el pg_hba.conf, habilite toda la red para las pruebas


Cuando escaneo los puertos del servidor que me quiero conectar no me muestra el 
de postgres


El netstat me trae esto

Pero cuando me quiero conectar me da este error:

​
​

De: Horacio Miranda mailto:hmira...@gmail.com>>
Enviado: jueves, 01 de septiembre de 2022 06:18 p.m.
Para: Romero, Fernando
Cc: pgsql-es-ay...@postgresql.org<mailto:pgsql-es-ay...@postgresql.org>
Asunto: Re: Consulta conexión y puerto



On 2/09/2022, at 5:20 AM, Romero, Fernando 
mailto:fernando.rom...@trenesargentinos.gob.ar>>
 wrote:

Hola como estan.
Hola
Tengo problema con las conexiones desde la red, a la base se conectan desde la 
lan.
El tema que no veo el puerto 5432 desde los otros host de la red y si miro lso 
puertos abiertos en el servidor
cuando hago un scaneo en el localhost me muestra el 5432 pero si lo hago sobre 
la ip ya no me lo muestra

Por defecto postgresql tiene un linea en el postgresql.conf
listen_addresses = 'localhost’

Cambialo por
listen_addresses = ‘*’
Esto abre el puerto en el localhost y en las interfaces o puedes poner la IP de 
la tarjeta  o puedes poner una lista separada por comas.

el archivo pg_hba.conf maneja los accesos.

asegurate que el archivo que estas editando sea el correcto, revisa el PID del 
proceso que tiene el puerto 5432

lsof -p 

te dice los open files del PID del postgresql.

netstat -nap | grep 5432 ( te da mas información ).

si estas usando postgresql como RPM en centos/redhat deberia estar con las 
reglas selinux OK.

rpm -V $(rpm -qa | grep postgresql) debiera verificar todos los contenidos que 
no hayan sido cambiados.

Espero que esto te ayude.

​

Tengo habilitado el puerto y el listen en el postgresql.conf para todos los host
Que me esta faltando?

Saludos
“El contenido del presente mensaje (y sus anexos) es privado, confidencial y de 
exclusivo uso para el destinatario referenciado; es de público conocimiento que 
las comunicaciones por medio de Internet no permiten asegurar ni garantizar la 
confidencialidad de los mensajes transmitidos, así como tampoco su integridad o 
su correcta recepción; es por ello que SOFSE no se responsabiliza de posibles 
perjuicios derivados de la captura, incorporaciones de virus o cualquier otra 
manipulación efectuada por terceros. Las opiniones expresadas en este mensaje y 
en los archivos adjuntos son propias del remitente y no representan la opinión 
o políticas de SOFSE, salvo que se diga expresamente y el remitente se 
encuentre autorizado para ello”

“El contenido del presente mensaje (y sus anexos) es privado, confidencial y de 
exclusivo uso para el destinatario referenciado; es de público conocimiento que 
las comunicaciones por medio de Internet no permiten asegurar ni garantizar la 
confidencialidad de los mensajes transmitidos, así como tampoco su integridad o 
su correcta recepción; es por ello que SOFSE no se responsabiliza de posibles 
perjuicios derivados de la captura, incorporaciones de virus o cualquier otra 
manipulación efectuada por terceros. Las opiniones expresadas en este mensaje y 
en los archivos adjuntos son propias del remitente y no representan la opinión 
o políticas de SOFSE, salvo que se diga expresamente y el remitente se 
encuentre autorizado para ello”

“El contenido del presente mensaje (y sus anexos) es privado, confidencial y de 
exclusivo uso para el destinatario referenciado; es de público conocimiento que 
las comunicaciones por medio de Internet no permiten asegurar ni garantizar la 
confidencialidad de los mensajes transmitidos, así como tampoco su integridad o 
su correcta recepción; es por ello que SOFSE no se responsabiliza de posibles 
perjuicios derivados de la captura, incorporaciones de virus o cualquier otra 
manipulación efectuada por terceros. Las opiniones expresadas en este mensaje y 
en los archivos adjuntos son propias del remitente y no representan la opinión 
o políticas de SOFSE, salvo que se diga expresamente y el remitente se 
encuentre autorizado para ello”

Re: Consulta conexión y puerto

[Horacio Miranda]

Veo el puerto abierto para todas partes.

ifconfig 
para ver las IP de la maquina.

grep -i -R listen_addresses /var/lib/pgsql/

iptables -L 

puede que sea reglas de firewall. 

> On 2/09/2022, at 9:51 AM, Romero, Fernando 
>  wrote:
> 
> Hola Horacio gracias por tu respuesta.
> Sigo con el problema, el selinux ya lo tengo deshabilitado pero sigo sin ver 
> el puerto desde la red
> Lo del postgresql.conf lo tengo tal como pones, no se si tengo que cambiar el 
> targeted en el selinux
> 
> 
> Asi tengo el pg_hba.conf, habilite toda la red para las pruebas
> 
> 
> Cuando escaneo los puertos del servidor que me quiero conectar no me muestra 
> el de postgres
> 
> 
> El netstat me trae esto
> 
> Pero cuando me quiero conectar me da este error:
> 
> ​
> ​
> De: Horacio Miranda mailto:hmira...@gmail.com>>
> Enviado: jueves, 01 de septiembre de 2022 06:18 p.m.
> Para: Romero, Fernando
> Cc: pgsql-es-ay...@postgresql.org
> Asunto: Re: Consulta conexión y puerto
>  
> 
> 
>> On 2/09/2022, at 5:20 AM, Romero, Fernando 
>> > <mailto:fernando.rom...@trenesargentinos.gob.ar>> wrote:
>> 
>> Hola como estan.
> Hola
>> Tengo problema con las conexiones desde la red, a la base se conectan desde 
>> la lan.
>> El tema que no veo el puerto 5432 desde los otros host de la red y si miro 
>> lso puertos abiertos en el servidor
>> cuando hago un scaneo en el localhost me muestra el 5432 pero si lo hago 
>> sobre la ip ya no me lo muestra
>> 
> Por defecto postgresql tiene un linea en el postgresql.conf
> listen_addresses = 'localhost’ 
> 
> Cambialo por
> listen_addresses = ‘*’ 
> Esto abre el puerto en el localhost y en las interfaces o puedes poner la IP 
> de la tarjeta  o puedes poner una lista separada por comas.
> 
> el archivo pg_hba.conf maneja los accesos.
> 
> asegurate que el archivo que estas editando sea el correcto, revisa el PID 
> del proceso que tiene el puerto 5432
> 
> lsof -p 
> 
> te dice los open files del PID del postgresql.
> 
> netstat -nap | grep 5432 ( te da mas información ). 
> 
> si estas usando postgresql como RPM en centos/redhat deberia estar con las 
> reglas selinux OK.
> 
> rpm -V $(rpm -qa | grep postgresql) debiera verificar todos los contenidos 
> que no hayan sido cambiados.
> 
> Espero que esto te ayude. 
> 
>> ​
>> 
>> Tengo habilitado el puerto y el listen en el postgresql.conf para todos los 
>> host
>> Que me esta faltando?
>> 
>> Saludos
>> “El contenido del presente mensaje (y sus anexos) es privado, confidencial y 
>> de exclusivo uso para el destinatario referenciado; es de público 
>> conocimiento que las comunicaciones por medio de Internet no permiten 
>> asegurar ni garantizar la confidencialidad de los mensajes transmitidos, así 
>> como tampoco su integridad o su correcta recepción; es por ello que SOFSE no 
>> se responsabiliza de posibles perjuicios derivados de la captura, 
>> incorporaciones de virus o cualquier otra manipulación efectuada por 
>> terceros. Las opiniones expresadas en este mensaje y en los archivos 
>> adjuntos son propias del remitente y no representan la opinión o políticas 
>> de SOFSE, salvo que se diga expresamente y el remitente se encuentre 
>> autorizado para ello”
> 
> “El contenido del presente mensaje (y sus anexos) es privado, confidencial y 
> de exclusivo uso para el destinatario referenciado; es de público 
> conocimiento que las comunicaciones por medio de Internet no permiten 
> asegurar ni garantizar la confidencialidad de los mensajes transmitidos, así 
> como tampoco su integridad o su correcta recepción; es por ello que SOFSE no 
> se responsabiliza de posibles perjuicios derivados de la captura, 
> incorporaciones de virus o cualquier otra manipulación efectuada por 
> terceros. Las opiniones expresadas en este mensaje y en los archivos adjuntos 
> son propias del remitente y no representan la opinión o políticas de SOFSE, 
> salvo que se diga expresamente y el remitente se encuentre autorizado para 
> ello”

Re: Consulta conexión y puerto

[Horacio Miranda]

> On 2/09/2022, at 5:20 AM, Romero, Fernando 
>  wrote:
> 
> Hola como estan.
Hola
> Tengo problema con las conexiones desde la red, a la base se conectan desde 
> la lan.
> El tema que no veo el puerto 5432 desde los otros host de la red y si miro 
> lso puertos abiertos en el servidor
> cuando hago un scaneo en el localhost me muestra el 5432 pero si lo hago 
> sobre la ip ya no me lo muestra
> 
Por defecto postgresql tiene un linea en el postgresql.conf
listen_addresses = 'localhost’ 

Cambialo por
listen_addresses = ‘*’ 
Esto abre el puerto en el localhost y en las interfaces o puedes poner la IP de 
la tarjeta  o puedes poner una lista separada por comas.

el archivo pg_hba.conf maneja los accesos.

asegurate que el archivo que estas editando sea el correcto, revisa el PID del 
proceso que tiene el puerto 5432

lsof -p 

te dice los open files del PID del postgresql.

netstat -nap | grep 5432 ( te da mas información ). 

si estas usando postgresql como RPM en centos/redhat deberia estar con las 
reglas selinux OK.

rpm -V $(rpm -qa | grep postgresql) debiera verificar todos los contenidos que 
no hayan sido cambiados.

Espero que esto te ayude. 

> ​
> 
> Tengo habilitado el puerto y el listen en el postgresql.conf para todos los 
> host
> Que me esta faltando?
> 
> Saludos
> “El contenido del presente mensaje (y sus anexos) es privado, confidencial y 
> de exclusivo uso para el destinatario referenciado; es de público 
> conocimiento que las comunicaciones por medio de Internet no permiten 
> asegurar ni garantizar la confidencialidad de los mensajes transmitidos, así 
> como tampoco su integridad o su correcta recepción; es por ello que SOFSE no 
> se responsabiliza de posibles perjuicios derivados de la captura, 
> incorporaciones de virus o cualquier otra manipulación efectuada por 
> terceros. Las opiniones expresadas en este mensaje y en los archivos adjuntos 
> son propias del remitente y no representan la opinión o políticas de SOFSE, 
> salvo que se diga expresamente y el remitente se encuentre autorizado para 
> ello”

Re: Consulta conexión y puerto

[Romero, Fernando]

?Hola Oliver, estoy usando centos 8 que ya lo herede.

Justamente estoy viendo ese tema, intente deshabilitarlo poniendolo disabled 
pero no me levanta mas el linux.

No tengo problemas con el tema pruebas porque el servidor todavia no esta en 
produccion


Saludos


De: Olivier Gautherot 
Enviado: jueves, 01 de septiembre de 2022 02:58 p.m.
Para: Romero, Fernando
Cc: Lista PostgreSql
Asunto: Re: Consulta conexión y puerto

Hola Fernando,

Qué sistema/distribución estás usando? Puede ser una regla de cortafuego o un 
selinux que se mete en el camino.

Olivier Gautherot

Le jeu. 1 sept. 2022, 19:20, Romero, Fernando 
mailto:fernando.rom...@trenesargentinos.gob.ar>>
 a écrit :

Hola como estan.

Tengo problema con las conexiones desde la red, a la base se conectan desde la 
lan.

El tema que no veo el puerto 5432 desde los otros host de la red y si miro lso 
puertos abiertos en el servidor

cuando hago un scaneo en el localhost me muestra el 5432 pero si lo hago sobre 
la ip ya no me lo muestra


[cid:6203232f-b0ce-4f75-b6c3-2e9d90b25158]?


Tengo habilitado el puerto y el listen en el postgresql.conf para todos los host

Que me esta faltando?


Saludos

"El contenido del presente mensaje (y sus anexos) es privado, confidencial y de 
exclusivo uso para el destinatario referenciado; es de público conocimiento que 
las comunicaciones por medio de Internet no permiten asegurar ni garantizar la 
confidencialidad de los mensajes transmitidos, así como tampoco su integridad o 
su correcta recepción; es por ello que SOFSE no se responsabiliza de posibles 
perjuicios derivados de la captura, incorporaciones de virus o cualquier otra 
manipulación efectuada por terceros. Las opiniones expresadas en este mensaje y 
en los archivos adjuntos son propias del remitente y no representan la opinión 
o políticas de SOFSE, salvo que se diga expresamente y el remitente se 
encuentre autorizado para ello"
"El contenido del presente mensaje (y sus anexos) es privado, confidencial y de 
exclusivo uso para el destinatario referenciado; es de público conocimiento que 
las comunicaciones por medio de Internet no permiten asegurar ni garantizar la 
confidencialidad de los mensajes transmitidos, así como tampoco su integridad o 
su correcta recepción; es por ello que SOFSE no se responsabiliza de posibles 
perjuicios derivados de la captura, incorporaciones de virus o cualquier otra 
manipulación efectuada por terceros. Las opiniones expresadas en este mensaje y 
en los archivos adjuntos son propias del remitente y no representan la opinión 
o políticas de SOFSE, salvo que se diga expresamente y el remitente se 
encuentre autorizado para ello"

Re: Consulta conexión y puerto

[Francisco Olarte]

Buenas tardes ( aqui ) Fernando, un par de cosas:

1.- Mete las capturas en texto, mejor que en imagen, son mas faciles
de chequear.
2.- Para comprobar si esta abierto el puerto, dado que pareces estar
en una variante Unix, es mejor que uses telnet o netcat ( este ultimo,
nv, es el que uso yo, si le das unas cuantas -v te dice mas cosas de
como te falla la conexion y la hace muy parecido al psql ). Ademas te
evitas ( si realmente lo necesitabas ) andar trabajando como root.

> Tengo problema con las conexiones desde la red, a la base se conectan desde 
> la lan.
> El tema que no veo el puerto 5432 desde los otros host de la red y si miro 
> lso puertos abiertos en el servidor
> cuando hago un scaneo en el localhost me muestra el 5432 pero si lo hago 
> sobre la ip ya no me lo muestra

Mejor que escanear, conecta directo. Lo unico bueno de ese scan es que
te dice que el rutado funciona bien, pero eso lo podias haber
verificado haciendole un ssh que parece tienes en todos.

> Tengo habilitado el puerto y el listen en el postgresql.conf para todos los 
> host
Dado que la LAN parece OK los sospechosos habituales son firewall en
la maquina destino y/o typo en la conf, convendria que pusieras la
linea de listen y demas que usas, copiadas directamente, por si
alguien ve algun typo.

> Que me esta faltando?
Con esa info no se puede saber, si nos fiamos de que el listen y port
estan bien, mira firewalling, pero mejor pon por aqui el listen que
suele ser el culpable. El SO y version de la maquina en la 77 tambien
vendria bien ( por lo que sabemos, puede ser un C64 ).

Francisco Olarte.

Consulta conexión y puerto

[Romero, Fernando]

Hola como estan.

Tengo problema con las conexiones desde la red, a la base se conectan desde la 
lan.

El tema que no veo el puerto 5432 desde los otros host de la red y si miro lso 
puertos abiertos en el servidor

cuando hago un scaneo en el localhost me muestra el 5432 pero si lo hago sobre 
la ip ya no me lo muestra


[cid:6203232f-b0ce-4f75-b6c3-2e9d90b25158]?


Tengo habilitado el puerto y el listen en el postgresql.conf para todos los host

Que me esta faltando?


Saludos

"El contenido del presente mensaje (y sus anexos) es privado, confidencial y de 
exclusivo uso para el destinatario referenciado; es de público conocimiento que 
las comunicaciones por medio de Internet no permiten asegurar ni garantizar la 
confidencialidad de los mensajes transmitidos, así como tampoco su integridad o 
su correcta recepción; es por ello que SOFSE no se responsabiliza de posibles 
perjuicios derivados de la captura, incorporaciones de virus o cualquier otra 
manipulación efectuada por terceros. Las opiniones expresadas en este mensaje y 
en los archivos adjuntos son propias del remitente y no representan la opinión 
o políticas de SOFSE, salvo que se diga expresamente y el remitente se 
encuentre autorizado para ello"

Re: Consulta pg_hba.conf

[Jaime Casanova]

On Tue, Aug 30, 2022 at 05:51:24PM +0200, Juan José Santamaría Flecha wrote:
> El mar, 30 ago 2022 17:22, Romero, Fernando <
> fernando.rom...@trenesargentinos.gob.ar> escribió:
> 
> > Esta linea no habilita a todo lo que sigue?
> >
> > local   repmgr  repmgr  trust
> >
> > Pero esa línea no llega a leerla:
> 
> local   all all peer
> local   repmgr  repmgr  trust
> 
> Te está rechazando en la anterior.
> 

Cómo dice Juan José el archivo pg_hba.conf se lee secuencialmente, de
arriba hacía abajo. Y solo para que quede perfectamente claro cuando
encuentra una línea que coincida con la conexión, y all en users y all
en databases siempre aplica especialmente en localhost, trata de 
autenticar con la regla que se indique. El resultado de ese intento se
considera suficiente y no continua con las siguientes reglas en caso de
que falle la autenticación.

-- 
Jaime Casanova
Director de Servicios Profesionales
SystemGuards - Consultores de PostgreSQL

Re: Consulta pg_hba.conf

[Juan José Santamaría Flecha]

El mar, 30 ago 2022 17:22, Romero, Fernando <
fernando.rom...@trenesargentinos.gob.ar> escribió:

> Esta linea no habilita a todo lo que sigue?
>
> local   repmgr  repmgr  trust
>
> Pero esa línea no llega a leerla:

local   all all peer
local   repmgr  repmgr  trust

Te está rechazando en la anterior.

Un saludo,

Juan José Santamaría Flecha


>

Re: Consulta pg_hba.conf

[Romero, Fernando]

Esta linea no habilita a todo lo que sigue?

local   repmgr  repmgr  trust?


De: Juan José Santamaría Flecha 
Enviado: martes, 30 de agosto de 2022 12:16 p.m.
Para: Romero, Fernando
Cc: pgsql-es-ay...@postgresql.org
Asunto: Re: Consulta pg_hba.conf


On Tue, Aug 30, 2022 at 5:02 PM Romero, Fernando 
mailto:fernando.rom...@trenesargentinos.gob.ar>>
 wrote:

Me sigue dando error, no se si es un tema del orden.

Sí, es por el orden, las reglas del hba se aplican secuencialmente según están 
en el fichero. En tu caso, como falla en la primera regla la conexión es 
rechazada.

Un saludo,

Juan José Santamaría Flecha
"El contenido del presente mensaje (y sus anexos) es privado, confidencial y de 
exclusivo uso para el destinatario referenciado; es de público conocimiento que 
las comunicaciones por medio de Internet no permiten asegurar ni garantizar la 
confidencialidad de los mensajes transmitidos, así como tampoco su integridad o 
su correcta recepción; es por ello que SOFSE no se responsabiliza de posibles 
perjuicios derivados de la captura, incorporaciones de virus o cualquier otra 
manipulación efectuada por terceros. Las opiniones expresadas en este mensaje y 
en los archivos adjuntos son propias del remitente y no representan la opinión 
o políticas de SOFSE, salvo que se diga expresamente y el remitente se 
encuentre autorizado para ello"

Re: Consulta pg_hba.conf

[Juan José Santamaría Flecha]

On Tue, Aug 30, 2022 at 5:02 PM Romero, Fernando <
fernando.rom...@trenesargentinos.gob.ar> wrote:

> Me sigue dando error, no se si es un tema del orden.
>
Sí, es por el orden, las reglas del hba se aplican secuencialmente según
están en el fichero. En tu caso, como falla en la primera regla la conexión
es rechazada.

Un saludo,

Juan José Santamaría Flecha

Consulta pg_hba.conf

[Romero, Fernando]

Hola como estan

Tengo problemas con el usuario repmgr en el pg_hba.conf

No me deja conectar me da el error


psql: error: FATAL:  la autentificación Peer falló para el usuario «repmgr»


Esta es la conf que tengo:


# "local" is for Unix domain socket connections only
local   all all peer
local   repmgr  repmgr  trust
# IPv4 local connections:
hostall all 127.0.0.1/32scram-sha-256
local   repmgr  repmgr  trust
hostrepmgr  repmgr  192.168.0.186/32trust
hostrepmgr  repmgr  192.168.0.245/32trust
hostrepmgr  repmgr  192.168.0.177/32trust
hostrepmgr  repmgr  192.168.0.101/32trust

# IPv6 local connections:
hostall all ::1/128 scram-sha-256
# Allow replication connections from localhost, by a user with the
# replication privilege.
local   replication all peer
hostreplication all 127.0.0.1/32scram-sha-256
hostreplication all ::1/128 scram-sha-256
hostreplication repmgr  192.168.0.186/32trust
hostreplication repmgr  192.168.0.245/32trust
hostreplication repmgr  192.168.0.177/32trust
hostreplication repmgr  192.168.0.101/32trust

Como ultima prueba le agregue esta linea al local
local   repmgr  repmgr  trust?

Me sigue dando error, no se si es un tema del orden.

Saludos




"El contenido del presente mensaje (y sus anexos) es privado, confidencial y de 
exclusivo uso para el destinatario referenciado; es de público conocimiento que 
las comunicaciones por medio de Internet no permiten asegurar ni garantizar la 
confidencialidad de los mensajes transmitidos, así como tampoco su integridad o 
su correcta recepción; es por ello que SOFSE no se responsabiliza de posibles 
perjuicios derivados de la captura, incorporaciones de virus o cualquier otra 
manipulación efectuada por terceros. Las opiniones expresadas en este mensaje y 
en los archivos adjuntos son propias del remitente y no representan la opinión 
o políticas de SOFSE, salvo que se diga expresamente y el remitente se 
encuentre autorizado para ello"

Re: Optimización de consulta

[Álvaro Hernández]

On 8/6/22 4:21, Horacio Miranda wrote:
Lo que dice Alvaro a esta altura solo hago un ( click guardar ) y lo 
voy a revisar bien. por que si lo usa Alvaro o participa Alvaro es por 
algo.


Encuentro que pgtune es un buen punto de partida  junto con Dexter, 
pero si quieres cosas mas finas definitivamente ese proyecto lo voy a 
revisar bien.  ( el que propuso Alvaro ).



On 8/06/2022, at 1:39 PM, Guillermo E. Villanueva 
 wrote:


Ups no me digas eso a esta altura Alvaro , uso mucho pgtune en 
servidores on premise.

Voy a tener que hacerme tiempo para estudiar esa guía.


    Gracias Horacio, Guillermo por vuestros comentarios. Mi opinión es 
que pgtune puede no ser una buena base, puede ser incluso 
*contraproducente*. Por ejemplo, max_connections:


a) Debería estar ligado a las CPUs (me sorprende no lo esté)
b) Debería dar un valor muy diferente según si usas un pool de 
conexiones que si no lo usas. Y si lo usas, a su vez puede depender de 
si está en modo sesión o transacción.


    Pruebo a generar una configuración para 2 cores. Me recomienda 
max_connections = 200. Eso puede destrozar el rendimiento de la base de 
datos. Lo explico bien, junto a otros parámetros, en esta charla que 
está en español: 
https://aht.es/#talks-configuracion_de_postgresql_para_seres_humanos


    Y así podría seguir con muchos parámetros. Si fuera tan fácil 
determinar los valores, ¿por qué no lo hace Postgres automáticamente, 
por qué no "embebe" pgTune?



    Espero os valga la guía, y la web en general de postgresqlco.nf. 
Aunque sólo sea una pequeña ayuda, porque al final, tunear Postgres, nos 
guste o no, es un "arte". No es, y lo digo con todos mis máximos 
respetos, un "simple formulario web".



    Saludos,

    Álvaro


--

Alvaro Hernandez


---
OnGres






El mar, 7 jun 2022 a las 19:01, Álvaro Hernández () 
escribió:




On 7/6/22 22:36, Horacio Miranda wrote:
> Para terminar, recuerda hacer tuning de tu base con pgtune
> https://pgtune.leopard.in.ua/ No pongas mucha RAM solo la que
> necesites para que opere bien.  ( al final del postgresql.conf ) y
> suerte con tus bases, espero que esta informaci'on sea util
para lo
> que necesites.

 pgtune hace recomendaciones demasiado estáticas, que pueden
llegar
a ser malas o incluso contraproducentes. En su lugar, es mejor
"seguir
una guía" que te ayude a personalizar los parámetros a tu caso
particular. En particular, me permito recomendar
https://postgresqlco.nf/tuning-guide (proyecto del que formo parte;
perdón por la auto referencia, pero espero sea útil).


 Saludos,

 Álvaro


-- 


Alvaro Hernandez


---
OnGres

Re: Optimización de consulta

[Eduardo Arenas]

*Alvaro,* TREMENDO APORTE!, idem voy a tener que leer la guía!

*Guillermo*, Sería bueno que mandes más antecedentes de tu problema,
esquema real de tablas y la consulta en sí que estás haciendo. Muchas veces
los join se pueden optimizar con funciones ventana, pero hay que mirar la
consulta, correrla como para poder ayudarte en detalle

Saludos cordiales,

Eduardo Arenas

El mar, 7 jun 2022 a la(s) 18:01, Álvaro Hernández (a...@ongres.com)
escribió:

>
>
> On 7/6/22 22:36, Horacio Miranda wrote:
> > Para terminar, recuerda hacer tuning de tu base con pgtune
> > https://pgtune.leopard.in.ua/ No pongas mucha RAM solo la que
> > necesites para que opere bien.  ( al final del postgresql.conf ) y
> > suerte con tus bases, espero que esta informaci'on sea util para lo
> > que necesites.
>
>  pgtune hace recomendaciones demasiado estáticas, que pueden llegar
> a ser malas o incluso contraproducentes. En su lugar, es mejor "seguir
> una guía" que te ayude a personalizar los parámetros a tu caso
> particular. En particular, me permito recomendar
> https://postgresqlco.nf/tuning-guide (proyecto del que formo parte;
> perdón por la auto referencia, pero espero sea útil).
>
>
>  Saludos,
>
>  Álvaro
>
>
> --
>
> Alvaro Hernandez
>
>
> ---
> OnGres
>
>
>
>
>

Re: Optimización de consulta

[Horacio Miranda]

Lo que dice Alvaro a esta altura solo hago un ( click guardar ) y lo voy a 
revisar bien. por que si lo usa Alvaro o participa Alvaro es por algo. 

Encuentro que pgtune es un buen punto de partida  junto con Dexter, pero si 
quieres cosas mas finas definitivamente ese proyecto lo voy a revisar bien.  ( 
el que propuso Alvaro ).


> On 8/06/2022, at 1:39 PM, Guillermo E. Villanueva  
> wrote:
> 
> Ups no me digas eso a esta altura Alvaro , uso mucho pgtune en servidores 
> on premise.
> Voy a tener que hacerme tiempo para estudiar esa guía.
> 
> El mar, 7 jun 2022 a las 19:01, Álvaro Hernández ( >) escribió:
> 
> 
> On 7/6/22 22:36, Horacio Miranda wrote:
> > Para terminar, recuerda hacer tuning de tu base con pgtune 
> > https://pgtune.leopard.in.ua/  No pongas 
> > mucha RAM solo la que 
> > necesites para que opere bien.  ( al final del postgresql.conf ) y 
> > suerte con tus bases, espero que esta informaci'on sea util para lo 
> > que necesites.
> 
>  pgtune hace recomendaciones demasiado estáticas, que pueden llegar 
> a ser malas o incluso contraproducentes. En su lugar, es mejor "seguir 
> una guía" que te ayude a personalizar los parámetros a tu caso 
> particular. En particular, me permito recomendar 
> https://postgresqlco.nf/tuning-guide  
> (proyecto del que formo parte; 
> perdón por la auto referencia, pero espero sea útil).
> 
> 
>  Saludos,
> 
>  Álvaro
> 
> 
> -- 
> 
> Alvaro Hernandez
> 
> 
> ---
> OnGres
> 
> 

Re: Optimización de consulta

[Guillermo E. Villanueva]

Ups no me digas eso a esta altura Alvaro , uso mucho pgtune en
servidores on premise.
Voy a tener que hacerme tiempo para estudiar esa guía.

El mar, 7 jun 2022 a las 19:01, Álvaro Hernández ()
escribió:

>
>
> On 7/6/22 22:36, Horacio Miranda wrote:
> > Para terminar, recuerda hacer tuning de tu base con pgtune
> > https://pgtune.leopard.in.ua/ No pongas mucha RAM solo la que
> > necesites para que opere bien.  ( al final del postgresql.conf ) y
> > suerte con tus bases, espero que esta informaci'on sea util para lo
> > que necesites.
>
>  pgtune hace recomendaciones demasiado estáticas, que pueden llegar
> a ser malas o incluso contraproducentes. En su lugar, es mejor "seguir
> una guía" que te ayude a personalizar los parámetros a tu caso
> particular. En particular, me permito recomendar
> https://postgresqlco.nf/tuning-guide (proyecto del que formo parte;
> perdón por la auto referencia, pero espero sea útil).
>
>
>  Saludos,
>
>  Álvaro
>
>
> --
>
> Alvaro Hernandez
>
>
> ---
> OnGres
>
>
>

Re: Optimización de consulta

[Guillermo E. Villanueva]

Horacio muchas gracias por tu aporte, tal como decís, ahora no usa los
índices, pero si sigue creciendo la base, posiblemente mas adelante los
usará y andará mejor.
Usé varios de los visualizadores online, son muy buenos.
Buenísimo lo de tu proyecto Dexter. Le voy a echar un vistazo.

Uso bastante pgtune, pero, sirve para bases de datos en cloud como google
sql (postgres) ?

El mar, 7 jun 2022 a las 17:36, Horacio Miranda ()
escribió:

> Solo para complementar.
> On 8/06/2022 6:41 am, Guillermo E. Villanueva wrote:
>
> Entendido, gracias
>
> El mar, 7 jun 2022 a las 15:18, Anthony Sotolongo ()
> escribió:
>
>> Hola
>>
>> El mar., 7 de junio de 2022 2:08 p. m., Guillermo E. Villanueva <
>> guillermo...@gmail.com> escribió:
>>
>>> Muchas gracias por tu respuesta Alvaro, tal como suponias, despues de
>>> hacer:
>>> create index idx1 on product_(status);
>>> create index idx2 on product_(qty);
>>> set enable_seqscan to 0;
>>>
>>> No mejoró la performance.  Demora lo mismo o un poquito mas.
>>> De nuevo muchas gracias.
>>>
>>> Para ver lo que hace el postgresql  ( si usa el cache buffers ) trata de
> hacer lo siguiente:
>
> explain (buffers,analyze) select . ;
>
> En lo personal el plan lo miro con https://explain.depesz.com/ te muestra
> algunas cosas utiles sobre los planes, el hints es basico pero puede
> ayudar.  ( puedes anonymitizar el plan si tienes nombres sensibles).
> Sobre los indices,  puede que no te hagan falta ahora puede que mas
> adelante te hagan falta, crearlos o no crearlos depende de que tan seguido
> mires la base. en lo personal estoy probando en mis bases de datos un
> proyecto llamada Dexter ( que crea indices de forma automatica ), por lo
> menos los basicos.
>
> Pegale una mirada si quieres. https://github.com/ankane/dexter
>
> Recuerda que postgresql es una de las bases libres mas avanzada del mundo
> y si no usa indices es por que seguramente las saca del buffer o el costo
> de usar indices como ya te lo mensionaron es mas alto que hacer full scan
> ).
> Para terminar, recuerda hacer tuning de tu base con pgtune
> https://pgtune.leopard.in.ua/  No pongas mucha RAM solo la que necesites
> para que opere bien.  ( al final del postgresql.conf ) y suerte con tus
> bases, espero que esta informaci'on sea util para lo que necesites.
>
> Guillermo
>>> offtopic:
>>> Aprovecho para preguntar, ese "set" va a durar lo que dura la sesión? o
>>> es un set para todo el servidor y queda hasta un reinicio?
>>>
>>
>> El set ese va a durar lo que dure su sesión
>>
>> Saludos
>>
>>>
>>>
>>>
>>> El mar, 7 jun 2022 a las 14:59, Alvaro Herrera ()
>>> escribió:
>>>
>>>> Guillermo E. Villanueva escribió:
>>>>
>>>> > *product_.status = 1 and and product_.qty > 0*
>>>> >
>>>> > provocan seq. scan y el mayor costo y tiempo de mi consulta
>>>> > la tabla product_ tiene 69300 filas
>>>> > status = 1 son 49500
>>>> > qty > 0 son 65700
>>>> >
>>>> > el explain me dice:
>>>> > ->  Parallel Seq Scan on product_  (cost=0.00..19483.64 rows=19580
>>>> > width=30) (actual time=0.032..39.454 rows=15674 loops=3)
>>>> > Filter: ((qty > '0'::numeric) AND (status = 1))
>>>> >  Rows Removed by Filter: 7454
>>>> >
>>>> > Si creo índices individuales o combinando ambas columnas no mejora,
>>>> sigue
>>>> > haciendo seq. scan
>>>>
>>>> La tabla es muy pequeña y las cláusulas son poco selectivas, así que el
>>>> seqscan ya es la mejor estrategia.  Pero prueba haciendo "set
>>>> enable_seqscan to 0" a ver si usando un índice anda más rápido (dudoso).
>>>> Si la tabla fuera muy grande y la fracción de registros que tienen
>>>> status=1 AND qty>0 es suficientemente pequeña, podría resultar en un
>>>> plan distinto/mejor.
>>>>
>>>> --
>>>> Álvaro Herrera PostgreSQL Developer  —
>>>> https://www.EnterpriseDB.com/
>>>> "Oh, great altar of passive entertainment, bestow upon me thy
>>>> discordant images
>>>> at such speed as to render linear thought impossible" (Calvin a la TV)
>>>>
>>>

Re: Optimización de consulta

[Álvaro Hernández]

On 7/6/22 22:36, Horacio Miranda wrote:
Para terminar, recuerda hacer tuning de tu base con pgtune 
https://pgtune.leopard.in.ua/ No pongas mucha RAM solo la que 
necesites para que opere bien.  ( al final del postgresql.conf ) y 
suerte con tus bases, espero que esta informaci'on sea util para lo 
que necesites.


    pgtune hace recomendaciones demasiado estáticas, que pueden llegar 
a ser malas o incluso contraproducentes. En su lugar, es mejor "seguir 
una guía" que te ayude a personalizar los parámetros a tu caso 
particular. En particular, me permito recomendar 
https://postgresqlco.nf/tuning-guide (proyecto del que formo parte; 
perdón por la auto referencia, pero espero sea útil).



    Saludos,

    Álvaro


--

Alvaro Hernandez


---
OnGres

Re: Optimización de consulta

[Horacio Miranda]

Solo para complementar.

On 8/06/2022 6:41 am, Guillermo E. Villanueva wrote:

Entendido, gracias

El mar, 7 jun 2022 a las 15:18, Anthony Sotolongo 
() escribió:


Hola

El mar., 7 de junio de 2022 2:08 p. m., Guillermo E. Villanueva
 escribió:

Muchas gracias por tu respuesta Alvaro, tal como suponias,
despues de hacer:
create index idx1 on product_(status);
create index idx2 on product_(qty);
set enable_seqscan to 0;

No mejoró la performance.  Demora lo mismo o un poquito mas.
De nuevo muchas gracias.

Para ver lo que hace el postgresql  ( si usa el cache buffers ) trata de 
hacer lo siguiente:


explain (buffers,analyze) select . ;

En lo personal el plan lo miro con https://explain.depesz.com/ te 
muestra algunas cosas utiles sobre los planes, el hints es basico pero 
puede ayudar.  ( puedes anonymitizar el plan si tienes nombres sensibles).
Sobre los indices,  puede que no te hagan falta ahora puede que mas 
adelante te hagan falta, crearlos o no crearlos depende de que tan 
seguido mires la base. en lo personal estoy probando en mis bases de 
datos un proyecto llamada Dexter ( que crea indices de forma automatica 
), por lo menos los basicos.


Pegale una mirada si quieres. https://github.com/ankane/dexter

Recuerda que postgresql es una de las bases libres mas avanzada del 
mundo y si no usa indices es por que seguramente las saca del buffer o 
el costo de usar indices como ya te lo mensionaron es mas alto que hacer 
full scan ).
Para terminar, recuerda hacer tuning de tu base con pgtune 
https://pgtune.leopard.in.ua/  No pongas mucha RAM solo la que necesites 
para que opere bien.  ( al final del postgresql.conf ) y suerte con tus 
bases, espero que esta informaci'on sea util para lo que necesites.



Guillermo
offtopic:
Aprovecho para preguntar, ese "set" va a durar lo que dura la
sesión? o es un set para todo el servidor y queda hasta un
reinicio?


El set ese va a durar lo que dure su sesión

Saludos




El mar, 7 jun 2022 a las 14:59, Alvaro Herrera
() escribió:

Guillermo E. Villanueva escribió:

> *product_.status = 1 and and product_.qty > 0*
>
> provocan seq. scan y el mayor costo y tiempo de mi consulta
> la tabla product_ tiene 69300 filas
> status = 1 son 49500
> qty > 0 son 65700
>
> el explain me dice:
> ->  Parallel Seq Scan on product_ (cost=0.00..19483.64
rows=19580
> width=30) (actual time=0.032..39.454 rows=15674 loops=3)
>     Filter: ((qty > '0'::numeric) AND (status = 1))
>      Rows Removed by Filter: 7454
>
> Si creo índices individuales o combinando ambas columnas
no mejora, sigue
> haciendo seq. scan

La tabla es muy pequeña y las cláusulas son poco
selectivas, así que el
seqscan ya es la mejor estrategia.  Pero prueba haciendo "set
enable_seqscan to 0" a ver si usando un índice anda más
rápido (dudoso).
Si la tabla fuera muy grande y la fracción de registros
que tienen
status=1 AND qty>0 es suficientemente pequeña, podría
resultar en un
plan distinto/mejor.

-- 
Álvaro Herrera         PostgreSQL Developer  —

https://www.EnterpriseDB.com/ <https://www.EnterpriseDB.com/>
"Oh, great altar of passive entertainment, bestow upon me
thy discordant images
at such speed as to render linear thought impossible"
(Calvin a la TV)

Re: Optimización de consulta

[Guillermo E. Villanueva]

Entendido, gracias

El mar, 7 jun 2022 a las 15:18, Anthony Sotolongo ()
escribió:

> Hola
>
> El mar., 7 de junio de 2022 2:08 p. m., Guillermo E. Villanueva <
> guillermo...@gmail.com> escribió:
>
>> Muchas gracias por tu respuesta Alvaro, tal como suponias, despues de
>> hacer:
>> create index idx1 on product_(status);
>> create index idx2 on product_(qty);
>> set enable_seqscan to 0;
>>
>> No mejoró la performance.  Demora lo mismo o un poquito mas.
>> De nuevo muchas gracias.
>>
>> Guillermo
>> offtopic:
>> Aprovecho para preguntar, ese "set" va a durar lo que dura la sesión? o
>> es un set para todo el servidor y queda hasta un reinicio?
>>
>
> El set ese va a durar lo que dure su sesión
>
> Saludos
>
>>
>>
>>
>> El mar, 7 jun 2022 a las 14:59, Alvaro Herrera ()
>> escribió:
>>
>>> Guillermo E. Villanueva escribió:
>>>
>>> > *product_.status = 1 and and product_.qty > 0*
>>> >
>>> > provocan seq. scan y el mayor costo y tiempo de mi consulta
>>> > la tabla product_ tiene 69300 filas
>>> > status = 1 son 49500
>>> > qty > 0 son 65700
>>> >
>>> > el explain me dice:
>>> > ->  Parallel Seq Scan on product_  (cost=0.00..19483.64 rows=19580
>>> > width=30) (actual time=0.032..39.454 rows=15674 loops=3)
>>> > Filter: ((qty > '0'::numeric) AND (status = 1))
>>> >  Rows Removed by Filter: 7454
>>> >
>>> > Si creo índices individuales o combinando ambas columnas no mejora,
>>> sigue
>>> > haciendo seq. scan
>>>
>>> La tabla es muy pequeña y las cláusulas son poco selectivas, así que el
>>> seqscan ya es la mejor estrategia.  Pero prueba haciendo "set
>>> enable_seqscan to 0" a ver si usando un índice anda más rápido (dudoso).
>>> Si la tabla fuera muy grande y la fracción de registros que tienen
>>> status=1 AND qty>0 es suficientemente pequeña, podría resultar en un
>>> plan distinto/mejor.
>>>
>>> --
>>> Álvaro Herrera PostgreSQL Developer  —
>>> https://www.EnterpriseDB.com/
>>> "Oh, great altar of passive entertainment, bestow upon me thy discordant
>>> images
>>> at such speed as to render linear thought impossible" (Calvin a la TV)
>>>
>>

Re: Optimización de consulta

[Guillermo E. Villanueva]

Ok, muchas gracias Daymel

El mar, 7 jun 2022 a las 14:58, Daymel Bonne Solís ()
escribió:

>
>
> El mar, 7 jun 2022 a la(s) 12:21, Guillermo E. Villanueva (
> guillermo...@gmail.com) escribió:
>
>> Buenas tardes cómo andan? quizá me puedan dar una mano, estoy tratando de
>> optimizar una consulta con varios joins, agrupamientos y unos cuantos
>> filtros, según lo que puedo ver en el explain  las expresiones:
>>
>> *product_.status = 1 and and product_.qty > 0*
>>
>> provocan seq. scan y el mayor costo y tiempo de mi consulta
>> la tabla product_ tiene 69300 filas
>> status = 1 son 49500
>> qty > 0 son 65700
>>
>> el explain me dice:
>> ->  Parallel Seq Scan on product_  (cost=0.00..19483.64 rows=19580
>> width=30) (actual time=0.032..39.454 rows=15674 loops=3)
>> Filter: ((qty > '0'::numeric) AND (status = 1))
>>  Rows Removed by Filter: 7454
>>
>> Si creo índices individuales o combinando ambas columnas no mejora, sigue
>> haciendo seq. scan
>>
>> Creen que hay alguna forma de mejorarlo? o ya estoy en la mejor versión
>> de la query?
>>
>> Desde ya muchas gracias por las ideas.
>>
>
> La explicación del comportamiento viene dado por los datos que nos
> muestras:
>
> Total de registros: 69300
> Tuplas que cumplen con `status = 1` son 49500 representa el 71%
> Tuplas que cumplen con `qty > 0` son 49500 que son 84%
>
> Postgres no utilizará índices, es ménos costoso hacer un scan secuencial
> sobre la tabla que primero buscar en los índices y luego ir a la tabla para
> obtener los registros.
>
> Saludos
>
>

Re: Optimización de consulta

[Anthony Sotolongo]

Hola

El mar., 7 de junio de 2022 2:08 p. m., Guillermo E. Villanueva <
guillermo...@gmail.com> escribió:

> Muchas gracias por tu respuesta Alvaro, tal como suponias, despues de
> hacer:
> create index idx1 on product_(status);
> create index idx2 on product_(qty);
> set enable_seqscan to 0;
>
> No mejoró la performance.  Demora lo mismo o un poquito mas.
> De nuevo muchas gracias.
>
> Guillermo
> offtopic:
> Aprovecho para preguntar, ese "set" va a durar lo que dura la sesión? o es
> un set para todo el servidor y queda hasta un reinicio?
>

El set ese va a durar lo que dure su sesión

Saludos

>
>
>
> El mar, 7 jun 2022 a las 14:59, Alvaro Herrera ()
> escribió:
>
>> Guillermo E. Villanueva escribió:
>>
>> > *product_.status = 1 and and product_.qty > 0*
>> >
>> > provocan seq. scan y el mayor costo y tiempo de mi consulta
>> > la tabla product_ tiene 69300 filas
>> > status = 1 son 49500
>> > qty > 0 son 65700
>> >
>> > el explain me dice:
>> > ->  Parallel Seq Scan on product_  (cost=0.00..19483.64 rows=19580
>> > width=30) (actual time=0.032..39.454 rows=15674 loops=3)
>> > Filter: ((qty > '0'::numeric) AND (status = 1))
>> >  Rows Removed by Filter: 7454
>> >
>> > Si creo índices individuales o combinando ambas columnas no mejora,
>> sigue
>> > haciendo seq. scan
>>
>> La tabla es muy pequeña y las cláusulas son poco selectivas, así que el
>> seqscan ya es la mejor estrategia.  Pero prueba haciendo "set
>> enable_seqscan to 0" a ver si usando un índice anda más rápido (dudoso).
>> Si la tabla fuera muy grande y la fracción de registros que tienen
>> status=1 AND qty>0 es suficientemente pequeña, podría resultar en un
>> plan distinto/mejor.
>>
>> --
>> Álvaro Herrera PostgreSQL Developer  —
>> https://www.EnterpriseDB.com/
>> "Oh, great altar of passive entertainment, bestow upon me thy discordant
>> images
>> at such speed as to render linear thought impossible" (Calvin a la TV)
>>
>

Re: Optimización de consulta

[Guillermo E. Villanueva]

Muchas gracias por tu respuesta Alvaro, tal como suponias, despues de hacer:
create index idx1 on product_(status);
create index idx2 on product_(qty);
set enable_seqscan to 0;

No mejoró la performance.  Demora lo mismo o un poquito mas.
De nuevo muchas gracias.

Guillermo
offtopic:
Aprovecho para preguntar, ese "set" va a durar lo que dura la sesión? o es
un set para todo el servidor y queda hasta un reinicio?



El mar, 7 jun 2022 a las 14:59, Alvaro Herrera ()
escribió:

> Guillermo E. Villanueva escribió:
>
> > *product_.status = 1 and and product_.qty > 0*
> >
> > provocan seq. scan y el mayor costo y tiempo de mi consulta
> > la tabla product_ tiene 69300 filas
> > status = 1 son 49500
> > qty > 0 son 65700
> >
> > el explain me dice:
> > ->  Parallel Seq Scan on product_  (cost=0.00..19483.64 rows=19580
> > width=30) (actual time=0.032..39.454 rows=15674 loops=3)
> > Filter: ((qty > '0'::numeric) AND (status = 1))
> >  Rows Removed by Filter: 7454
> >
> > Si creo índices individuales o combinando ambas columnas no mejora, sigue
> > haciendo seq. scan
>
> La tabla es muy pequeña y las cláusulas son poco selectivas, así que el
> seqscan ya es la mejor estrategia.  Pero prueba haciendo "set
> enable_seqscan to 0" a ver si usando un índice anda más rápido (dudoso).
> Si la tabla fuera muy grande y la fracción de registros que tienen
> status=1 AND qty>0 es suficientemente pequeña, podría resultar en un
> plan distinto/mejor.
>
> --
> Álvaro Herrera PostgreSQL Developer  —
> https://www.EnterpriseDB.com/
> "Oh, great altar of passive entertainment, bestow upon me thy discordant
> images
> at such speed as to render linear thought impossible" (Calvin a la TV)
>

Re: Optimización de consulta

[Alvaro Herrera]

Guillermo E. Villanueva escribió:

> *product_.status = 1 and and product_.qty > 0*
> 
> provocan seq. scan y el mayor costo y tiempo de mi consulta
> la tabla product_ tiene 69300 filas
> status = 1 son 49500
> qty > 0 son 65700
> 
> el explain me dice:
> ->  Parallel Seq Scan on product_  (cost=0.00..19483.64 rows=19580
> width=30) (actual time=0.032..39.454 rows=15674 loops=3)
> Filter: ((qty > '0'::numeric) AND (status = 1))
>  Rows Removed by Filter: 7454
> 
> Si creo índices individuales o combinando ambas columnas no mejora, sigue
> haciendo seq. scan

La tabla es muy pequeña y las cláusulas son poco selectivas, así que el
seqscan ya es la mejor estrategia.  Pero prueba haciendo "set
enable_seqscan to 0" a ver si usando un índice anda más rápido (dudoso).
Si la tabla fuera muy grande y la fracción de registros que tienen
status=1 AND qty>0 es suficientemente pequeña, podría resultar en un
plan distinto/mejor.

-- 
Álvaro Herrera PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"Oh, great altar of passive entertainment, bestow upon me thy discordant images
at such speed as to render linear thought impossible" (Calvin a la TV)

Re: Optimización de consulta

[Daymel Bonne Solís]

El mar, 7 jun 2022 a la(s) 12:21, Guillermo E. Villanueva (
guillermo...@gmail.com) escribió:

> Buenas tardes cómo andan? quizá me puedan dar una mano, estoy tratando de
> optimizar una consulta con varios joins, agrupamientos y unos cuantos
> filtros, según lo que puedo ver en el explain  las expresiones:
>
> *product_.status = 1 and and product_.qty > 0*
>
> provocan seq. scan y el mayor costo y tiempo de mi consulta
> la tabla product_ tiene 69300 filas
> status = 1 son 49500
> qty > 0 son 65700
>
> el explain me dice:
> ->  Parallel Seq Scan on product_  (cost=0.00..19483.64 rows=19580
> width=30) (actual time=0.032..39.454 rows=15674 loops=3)
> Filter: ((qty > '0'::numeric) AND (status = 1))
>  Rows Removed by Filter: 7454
>
> Si creo índices individuales o combinando ambas columnas no mejora, sigue
> haciendo seq. scan
>
> Creen que hay alguna forma de mejorarlo? o ya estoy en la mejor versión de
> la query?
>
> Desde ya muchas gracias por las ideas.
>

La explicación del comportamiento viene dado por los datos que nos muestras:

Total de registros: 69300
Tuplas que cumplen con `status = 1` son 49500 representa el 71%
Tuplas que cumplen con `qty > 0` son 49500 que son 84%

Postgres no utilizará índices, es ménos costoso hacer un scan secuencial
sobre la tabla que primero buscar en los índices y luego ir a la tabla para
obtener los registros.

Saludos

Optimización de consulta

[Guillermo E. Villanueva]

Buenas tardes cómo andan? quizá me puedan dar una mano, estoy tratando de
optimizar una consulta con varios joins, agrupamientos y unos cuantos
filtros, según lo que puedo ver en el explain  las expresiones:

*product_.status = 1 and and product_.qty > 0*

provocan seq. scan y el mayor costo y tiempo de mi consulta
la tabla product_ tiene 69300 filas
status = 1 son 49500
qty > 0 son 65700

el explain me dice:
->  Parallel Seq Scan on product_  (cost=0.00..19483.64 rows=19580
width=30) (actual time=0.032..39.454 rows=15674 loops=3)
Filter: ((qty > '0'::numeric) AND (status = 1))
 Rows Removed by Filter: 7454

Si creo índices individuales o combinando ambas columnas no mejora, sigue
haciendo seq. scan

Creen que hay alguna forma de mejorarlo? o ya estoy en la mejor versión de
la query?

Desde ya muchas gracias por las ideas.

Datos de mi server:
PostgreSQL 13.6 on x86_64-pc-linux-gnu, compiled by Debian clang version
12.0.1, 64-bit

Re: Consulta sobre nodos master y replicas

[Jaime Soler]

Buenas,

El jue, 11 nov 2021 a las 11:56, Rodrigo Emmanuel Cordero (<
rodrigo.cord...@hotmail.es>) escribió:

> Buen día Jaime, muchísimas gracias.
> En el día de ayer luego de que me comentaras lo del health, y verificando
> la documentación que me pasaste pude identificar cual es el problema.
> Cuando solo tenes un nodo activo, el mismo queda como master (leader)
>
>
>
> Del lado del haproxy hay un httpchk que identifica según el endpoint si el
> mismo está disponible para "master" o bien como "replica"
>
>
>
> Lo que hace el haproxy es balancear entre un master y una replica como
> contingencia en caso que uno no quede disponible y además para balancear la
> lectura a la base de datos, lo cierto es que cuando tenes un cluster de dos
> nodos uno es de lectura y escritura y el otro es solo de lectura.
>

En la configuración actual tienes 3 servidores de base de datos (
172.16.109.231,172.16.109.232 y 172.16.109.233)  escuchando en el puerto
6432.



> Si cambias este check en el binding de réplica por "master" va a retornar
> 200 y por ende va a dejar disponible el puerto 5001 para su conexión.
>

Esto no le veo sentido alguno, me refiero a que cada puerto tiene una
finalidad específica. 5000 te redirige al master que quede vivo y 5001 a
las réplicas que aún sobrevivan.  Y de ahí, tu aplicación usará lo el 5000
si sólo configura 1 datasource o si está preparada para balancear lecturas,
entonces podrás usar un segundo datasource al puerto 5001, bueno como
posible opción.

De esta manera tanto el puerto 5000 y 5001 quedan activos.
> Para que quede un solo nodo activo con los dos puertos escuchando, el
> option httpchk del listener de replicas tiene que ser cambiado por master.
>

Yo usaría para el listen replicas el healthcheck /replica .

>
>
>
> Siendo esta la solución, entiendo que es recomendable tener un clúster de
> 3 o más nodos, simplemente por esto. Porque de tener un clúster de dos
> nodos hay más posibilidades que se dispare una alarma de conectividad con
> el puerto de lectura en el caso que uno no quede disponible.
>

En tu caso si sólo tienes 2 instancias de base de datos, convendría que
borrases la línea del servidor que no existe. Aunque generalmente Patroni
si lo montas con replicación síncrona, entonces uses 3 servidores de base
de datos, todo depende de los requisitos de HA, carga y balanceo de carga
...

>
> Muchísimas gracias nuevamente Jaime, pronto les estaré consultando por
> otro tema que tenemos en el clúster ya que necesito identificar de donde
> proviene y como resolver un lag que estamos teniendo.
>
> Saludos,
>
>
> Rodrigo Cordero
>
> --
> *De:* Jaime Soler 
> *Enviado:* jueves, 11 de noviembre de 2021 06:07
> *Para:* Rodrigo Emmanuel Cordero 
> *Cc:* pgsql-es-ay...@postgresql.org 
> *Asunto:* Re: Consulta sobre nodos master y replicas
>
> Ambos puertos, 5000 y 5001 se deberían de poder usar. La diferencia entre
> ambos es, a la hora de asignarte un servidor por defecto, es el número de
> chequeos correctos que tienen que devolver el api-rest ,
> Para el puerto 5000, volverá a considerar un servidor como disponible
> después de 4 healthcheck ok's:   default-server inter 3s fastinter 1s fall
> 3 rise 4 on-marked-down shutdown-sessions
> Y 2 healthcheck's ok en el caso del puerto 5001:   default-server inter 3s
> fastinter 1s fall 3 rise 2 on-marked-down shutdown-sessions
> La cuestión que creo que debéis de darle una vuelta es saber, cómo
> queréis ustedes manejar las conexiones desde el aplicativo, sí siempre van
> al master o permite la aplicación balanceo de carga y usen conexiones a
> replicas, o replicas con o sin sincronismo...
>
> Un saludo
>
> El mié, 10 nov 2021 a las 18:42, Rodrigo Emmanuel Cordero (<
> rodrigo.cord...@hotmail.es>) escribió:
>
> Hola Jaime, muchas gracias por contestar.
> Es cierto, utilizamos patroni con el healthcheck, el comportamiento al
> pasar de un nodo a otro es normal pero cuando quedan más de un nodo activo.
> El problema que estamos teniendo puntualmente es que, cuando solo nos queda
> un solo nodo activo el único puerto al que podemos conectarnos es al 5000,
> que apunta de igual manera a cada nodo al igual que el puerto 5001. Este
> comportamiento es normal o deberíamos poder conectarnos a ambos puertos del
> haproxy si solo queda un nodo de postgres activo?
>
> Muchas gracias,
>
> Rodrigo Cordero
> --
> *De:* Jaime Soler 
> *Enviado:* miércoles, 10 de noviembre de 2021 08:21
> *Para:* Rodrigo Emmanuel Cordero 
> *Cc:* Jaime Casanova ;
> pgsql-es-ay...@postgresql.org 
> *Asunto:* Re: Consulta sobre nodos master y replicas
>
> Creo que lo que estás usando es Patroni, que ofrece la pos

RE: Consulta sobre nodos master y replicas

[Rodrigo Emmanuel Cordero]

Buen día Jaime, muchísimas gracias.
En el día de ayer luego de que me comentaras lo del health, y verificando la 
documentación que me pasaste pude identificar cual es el problema.
Cuando solo tenes un nodo activo, el mismo queda como master (leader)

[cid:8249e855-c12d-44b5-b165-805525bf57c5]

Del lado del haproxy hay un httpchk que identifica según el endpoint si el 
mismo está disponible para "master" o bien como "replica"

[cid:2d875205-f17e-476d-9aa2-a0a9baed2407]

Lo que hace el haproxy es balancear entre un master y una replica como 
contingencia en caso que uno no quede disponible y además para balancear la 
lectura a la base de datos, lo cierto es que cuando tenes un cluster de dos 
nodos uno es de lectura y escritura y el otro es solo de lectura.
Si cambias este check en el binding de réplica por "master" va a retornar 200 y 
por ende va a dejar disponible el puerto 5001 para su conexión.
De esta manera tanto el puerto 5000 y 5001 quedan activos.
Para que quede un solo nodo activo con los dos puertos escuchando, el option 
httpchk del listener de replicas tiene que ser cambiado por master.

[cid:f36f76f4-db05-4659-bbf9-ecf96649b5ab]

Siendo esta la solución, entiendo que es recomendable tener un clúster de 3 o 
más nodos, simplemente por esto. Porque de tener un clúster de dos nodos hay 
más posibilidades que se dispare una alarma de conectividad con el puerto de 
lectura en el caso que uno no quede disponible.

Muchísimas gracias nuevamente Jaime, pronto les estaré consultando por otro 
tema que tenemos en el clúster ya que necesito identificar de donde proviene y 
como resolver un lag que estamos teniendo.

Saludos,


Rodrigo Cordero


De: Jaime Soler 
Enviado: jueves, 11 de noviembre de 2021 06:07
Para: Rodrigo Emmanuel Cordero 
Cc: pgsql-es-ay...@postgresql.org 
Asunto: Re: Consulta sobre nodos master y replicas

Ambos puertos, 5000 y 5001 se deberían de poder usar. La diferencia entre ambos 
es, a la hora de asignarte un servidor por defecto, es el número de chequeos 
correctos que tienen que devolver el api-rest ,
Para el puerto 5000, volverá a considerar un servidor como disponible después 
de 4 healthcheck ok's:   default-server inter 3s fastinter 1s fall 3 rise 4 
on-marked-down shutdown-sessions
Y 2 healthcheck's ok en el caso del puerto 5001:   default-server inter 3s 
fastinter 1s fall 3 rise 2 on-marked-down shutdown-sessions
La cuestión que creo que debéis de darle una vuelta es saber, cómo queréis 
ustedes manejar las conexiones desde el aplicativo, sí siempre van al master o 
permite la aplicación balanceo de carga y usen conexiones a replicas, o 
replicas con o sin sincronismo...

Un saludo

El mié, 10 nov 2021 a las 18:42, Rodrigo Emmanuel Cordero 
(mailto:rodrigo.cord...@hotmail.es>>) escribió:
Hola Jaime, muchas gracias por contestar.
Es cierto, utilizamos patroni con el healthcheck, el comportamiento al pasar de 
un nodo a otro es normal pero cuando quedan más de un nodo activo. El problema 
que estamos teniendo puntualmente es que, cuando solo nos queda un solo nodo 
activo el único puerto al que podemos conectarnos es al 5000, que apunta de 
igual manera a cada nodo al igual que el puerto 5001. Este comportamiento es 
normal o deberíamos poder conectarnos a ambos puertos del haproxy si solo queda 
un nodo de postgres activo?

Muchas gracias,

Rodrigo Cordero

De: Jaime Soler mailto:jaime.so...@gmail.com>>
Enviado: miércoles, 10 de noviembre de 2021 08:21
Para: Rodrigo Emmanuel Cordero 
mailto:rodrigo.cord...@hotmail.es>>
Cc: Jaime Casanova 
mailto:jcasa...@systemguards.com.ec>>; 
pgsql-es-ay...@postgresql.org<mailto:pgsql-es-ay...@postgresql.org> 
mailto:pgsql-es-ay...@postgresql.org>>
Asunto: Re: Consulta sobre nodos master y replicas

Creo que lo que estás usando es Patroni, que ofrece la posibilidad de tener 
haproxy como balanceador, usando como healthcheck la api rest que expone 
patroni en el puerto 8008.
El api rest, te da acceso a los nodos standby síncronos sobre el método /sync 
(https://github.com/zalando/patroni/blob/2f31e88bdc3f933f0c3fffdc6ea67a99a7c378cc/patroni/api.py#L151
 ) o los standby asínconos mediante el método /async 
(https://github.com/zalando/patroni/blob/2f31e88bdc3f933f0c3fffdc6ea67a99a7c378cc/patroni/api.py#L151
 )
En tu caso el puerto 5000 y el 5001 va a balancear las peticiones a cualquiera 
de los nodos de base de datos que esten vivos.
Creo que conviene que revises los endpoints de healcheck que ofrece patroni 
https://patroni.readthedocs.io/en/latest/rest_api.html#health-check-endpoints y 
adecuar la configuración del haproxy, en función a lo que necesites.

Un saludo.

El mié, 10 nov 2021 a las 2:22, Rodrigo Emmanuel Cordero 
(mailto:rodrigo.cord...@hotmail.es>>) escribió:
Un gusto Jaime, muchas gracias por contestar.
Disculpas... Efectivamente, hay un haproxy y adjunto el archivo de 
configuracion de

Re: Consulta sobre nodos master y replicas

[Jaime Soler]

Ambos puertos, 5000 y 5001 se deberían de poder usar. La diferencia entre
ambos es, a la hora de asignarte un servidor por defecto, es el número de
chequeos correctos que tienen que devolver el api-rest ,
Para el puerto 5000, volverá a considerar un servidor como disponible
después de 4 healthcheck ok's:   default-server inter 3s fastinter 1s fall
3 rise 4 on-marked-down shutdown-sessions
Y 2 healthcheck's ok en el caso del puerto 5001:   default-server inter 3s
fastinter 1s fall 3 rise 2 on-marked-down shutdown-sessions
La cuestión que creo que debéis de darle una vuelta es saber, cómo
queréis ustedes manejar las conexiones desde el aplicativo, sí siempre van
al master o permite la aplicación balanceo de carga y usen conexiones a
replicas, o replicas con o sin sincronismo...

Un saludo

El mié, 10 nov 2021 a las 18:42, Rodrigo Emmanuel Cordero (<
rodrigo.cord...@hotmail.es>) escribió:

> Hola Jaime, muchas gracias por contestar.
> Es cierto, utilizamos patroni con el healthcheck, el comportamiento al
> pasar de un nodo a otro es normal pero cuando quedan más de un nodo activo.
> El problema que estamos teniendo puntualmente es que, cuando solo nos queda
> un solo nodo activo el único puerto al que podemos conectarnos es al 5000,
> que apunta de igual manera a cada nodo al igual que el puerto 5001. Este
> comportamiento es normal o deberíamos poder conectarnos a ambos puertos del
> haproxy si solo queda un nodo de postgres activo?
>
> Muchas gracias,
>
> Rodrigo Cordero
> --
> *De:* Jaime Soler 
> *Enviado:* miércoles, 10 de noviembre de 2021 08:21
> *Para:* Rodrigo Emmanuel Cordero 
> *Cc:* Jaime Casanova ;
> pgsql-es-ay...@postgresql.org 
> *Asunto:* Re: Consulta sobre nodos master y replicas
>
> Creo que lo que estás usando es Patroni, que ofrece la posibilidad de
> tener haproxy como balanceador, usando como healthcheck la api rest que
> expone patroni en el puerto 8008.
> El api rest, te da acceso a los nodos standby síncronos sobre el método
> /sync (
> https://github.com/zalando/patroni/blob/2f31e88bdc3f933f0c3fffdc6ea67a99a7c378cc/patroni/api.py#L151
> ) o los standby asínconos mediante el método /async (
> https://github.com/zalando/patroni/blob/2f31e88bdc3f933f0c3fffdc6ea67a99a7c378cc/patroni/api.py#L151
> )
> En tu caso el puerto 5000 y el 5001 va a balancear las peticiones a
> cualquiera de los nodos de base de datos que esten vivos.
> Creo que conviene que revises los endpoints de healcheck que ofrece
> patroni
> https://patroni.readthedocs.io/en/latest/rest_api.html#health-check-endpoints
> y adecuar la configuración del haproxy, en función a lo que necesites.
>
> Un saludo.
>
> El mié, 10 nov 2021 a las 2:22, Rodrigo Emmanuel Cordero (<
> rodrigo.cord...@hotmail.es>) escribió:
>
> Un gusto Jaime, muchas gracias por contestar.
> Disculpas... Efectivamente, hay un haproxy y adjunto el archivo de
> configuracion del mismo para que puedas decirme si la configuracion es
> correcta.
>
> Muchas gracias,
>
> Rodrigo Cordero
>
> Get Outlook para Android <https://aka.ms/AAb9ysg>
> --
> *From:* Jaime Casanova 
> *Sent:* Tuesday, November 9, 2021 7:40:35 PM
> *To:* Rodrigo Emmanuel Cordero 
> *Cc:* pgsql-es-ay...@postgresql.org 
> *Subject:* Re: Consulta sobre nodos master y replicas
>
> On Tue, Nov 09, 2021 at 06:52:42PM +, Rodrigo Emmanuel Cordero wrote:
> > Hola, antes que nada un gusto en saludarlos.
> > Estoy teniendo una duda respecto al comportamiento del cluster con tres
> nodos de postgres (1 Master / 2 Replicas).
> > Cuando el nodo master se apaga, automáticamente uno de los nodos
> "replicas" toma el control del master, esto esta bien.
>
> en realidad, postgres no hace esto de forma automática. probablemente
> tienes una aplicación que hace esto.
>
> > Ahora la duda que tengo actualmente es cuando solo queda un solo nodo,
> el único puerto al cual es posible conectarse es el 5000, y el 5001 pierde
> conexión.
> > ¿Este comportamiento es normal?
> > ¿Teniendo un solo nodo activo, pueden quedar los puertos 5000 y 5001
> activos o esto ocurre solo cuando hay mas de un nodo activo?
> >
>
> y aqui se confirma el hecho de que tienes una aplicación haciendo esto.
> esos puertos no los usa postgres para nada.
>
> Sabes que estas usando para el failover? mi sospechas son haproxy o
> pg_auto_failover
>
> --
> Jaime Casanova
> Director de Servicios Profesionales
> SystemGuards - Consultores de PostgreSQL
>
>

RE: Consulta sobre nodos master y replicas

[Rodrigo Emmanuel Cordero]

Hola Jaime, muchas gracias por contestar.
Es cierto, utilizamos patroni con el healthcheck, el comportamiento al pasar de 
un nodo a otro es normal pero cuando quedan más de un nodo activo. El problema 
que estamos teniendo puntualmente es que, cuando solo nos queda un solo nodo 
activo el único puerto al que podemos conectarnos es al 5000, que apunta de 
igual manera a cada nodo al igual que el puerto 5001. Este comportamiento es 
normal o deberíamos poder conectarnos a ambos puertos del haproxy si solo queda 
un nodo de postgres activo?

Muchas gracias,

Rodrigo Cordero

De: Jaime Soler 
Enviado: miércoles, 10 de noviembre de 2021 08:21
Para: Rodrigo Emmanuel Cordero 
Cc: Jaime Casanova ; 
pgsql-es-ay...@postgresql.org 
Asunto: Re: Consulta sobre nodos master y replicas

Creo que lo que estás usando es Patroni, que ofrece la posibilidad de tener 
haproxy como balanceador, usando como healthcheck la api rest que expone 
patroni en el puerto 8008.
El api rest, te da acceso a los nodos standby síncronos sobre el método /sync 
(https://github.com/zalando/patroni/blob/2f31e88bdc3f933f0c3fffdc6ea67a99a7c378cc/patroni/api.py#L151
 ) o los standby asínconos mediante el método /async 
(https://github.com/zalando/patroni/blob/2f31e88bdc3f933f0c3fffdc6ea67a99a7c378cc/patroni/api.py#L151
 )
En tu caso el puerto 5000 y el 5001 va a balancear las peticiones a cualquiera 
de los nodos de base de datos que esten vivos.
Creo que conviene que revises los endpoints de healcheck que ofrece patroni 
https://patroni.readthedocs.io/en/latest/rest_api.html#health-check-endpoints y 
adecuar la configuración del haproxy, en función a lo que necesites.

Un saludo.

El mié, 10 nov 2021 a las 2:22, Rodrigo Emmanuel Cordero 
(mailto:rodrigo.cord...@hotmail.es>>) escribió:
Un gusto Jaime, muchas gracias por contestar.
Disculpas... Efectivamente, hay un haproxy y adjunto el archivo de 
configuracion del mismo para que puedas decirme si la configuracion es correcta.

Muchas gracias,

Rodrigo Cordero

Get Outlook para Android<https://aka.ms/AAb9ysg>

From: Jaime Casanova 
mailto:jcasa...@systemguards.com.ec>>
Sent: Tuesday, November 9, 2021 7:40:35 PM
To: Rodrigo Emmanuel Cordero 
mailto:rodrigo.cord...@hotmail.es>>
Cc: pgsql-es-ay...@postgresql.org<mailto:pgsql-es-ay...@postgresql.org> 
mailto:pgsql-es-ay...@postgresql.org>>
Subject: Re: Consulta sobre nodos master y replicas

On Tue, Nov 09, 2021 at 06:52:42PM +, Rodrigo Emmanuel Cordero wrote:
> Hola, antes que nada un gusto en saludarlos.
> Estoy teniendo una duda respecto al comportamiento del cluster con tres nodos 
> de postgres (1 Master / 2 Replicas).
> Cuando el nodo master se apaga, automáticamente uno de los nodos "replicas" 
> toma el control del master, esto esta bien.

en realidad, postgres no hace esto de forma automática. probablemente
tienes una aplicación que hace esto.

> Ahora la duda que tengo actualmente es cuando solo queda un solo nodo, el 
> único puerto al cual es posible conectarse es el 5000, y el 5001 pierde 
> conexión.
> ¿Este comportamiento es normal?
> ¿Teniendo un solo nodo activo, pueden quedar los puertos 5000 y 5001 activos 
> o esto ocurre solo cuando hay mas de un nodo activo?
>

y aqui se confirma el hecho de que tienes una aplicación haciendo esto.
esos puertos no los usa postgres para nada.

Sabes que estas usando para el failover? mi sospechas son haproxy o
pg_auto_failover

--
Jaime Casanova
Director de Servicios Profesionales
SystemGuards - Consultores de PostgreSQL

Re: Consulta sobre nodos master y replicas

[Jaime Soler]

Creo que lo que estás usando es Patroni, que ofrece la posibilidad de tener
haproxy como balanceador, usando como healthcheck la api rest que expone
patroni en el puerto 8008.
El api rest, te da acceso a los nodos standby síncronos sobre el método
/sync (
https://github.com/zalando/patroni/blob/2f31e88bdc3f933f0c3fffdc6ea67a99a7c378cc/patroni/api.py#L151
) o los standby asínconos mediante el método /async (
https://github.com/zalando/patroni/blob/2f31e88bdc3f933f0c3fffdc6ea67a99a7c378cc/patroni/api.py#L151
)
En tu caso el puerto 5000 y el 5001 va a balancear las peticiones a
cualquiera de los nodos de base de datos que esten vivos.
Creo que conviene que revises los endpoints de healcheck que ofrece patroni
https://patroni.readthedocs.io/en/latest/rest_api.html#health-check-endpoints
y adecuar la configuración del haproxy, en función a lo que necesites.

Un saludo.

El mié, 10 nov 2021 a las 2:22, Rodrigo Emmanuel Cordero (<
rodrigo.cord...@hotmail.es>) escribió:

> Un gusto Jaime, muchas gracias por contestar.
> Disculpas... Efectivamente, hay un haproxy y adjunto el archivo de
> configuracion del mismo para que puedas decirme si la configuracion es
> correcta.
>
> Muchas gracias,
>
> Rodrigo Cordero
>
> Get Outlook para Android <https://aka.ms/AAb9ysg>
> --
> *From:* Jaime Casanova 
> *Sent:* Tuesday, November 9, 2021 7:40:35 PM
> *To:* Rodrigo Emmanuel Cordero 
> *Cc:* pgsql-es-ay...@postgresql.org 
> *Subject:* Re: Consulta sobre nodos master y replicas
>
> On Tue, Nov 09, 2021 at 06:52:42PM +, Rodrigo Emmanuel Cordero wrote:
> > Hola, antes que nada un gusto en saludarlos.
> > Estoy teniendo una duda respecto al comportamiento del cluster con tres
> nodos de postgres (1 Master / 2 Replicas).
> > Cuando el nodo master se apaga, automáticamente uno de los nodos
> "replicas" toma el control del master, esto esta bien.
>
> en realidad, postgres no hace esto de forma automática. probablemente
> tienes una aplicación que hace esto.
>
> > Ahora la duda que tengo actualmente es cuando solo queda un solo nodo,
> el único puerto al cual es posible conectarse es el 5000, y el 5001 pierde
> conexión.
> > ¿Este comportamiento es normal?
> > ¿Teniendo un solo nodo activo, pueden quedar los puertos 5000 y 5001
> activos o esto ocurre solo cuando hay mas de un nodo activo?
> >
>
> y aqui se confirma el hecho de que tienes una aplicación haciendo esto.
> esos puertos no los usa postgres para nada.
>
> Sabes que estas usando para el failover? mi sospechas son haproxy o
> pg_auto_failover
>
> --
> Jaime Casanova
> Director de Servicios Profesionales
> SystemGuards - Consultores de PostgreSQL
>

Re: Consulta sobre nodos master y replicas

[Rodrigo Emmanuel Cordero]

Un gusto Jaime, muchas gracias por contestar.
Disculpas... Efectivamente, hay un haproxy y adjunto el archivo de 
configuracion del mismo para que puedas decirme si la configuracion es correcta.

Muchas gracias,

Rodrigo Cordero

Get Outlook para Android<https://aka.ms/AAb9ysg>

From: Jaime Casanova 
Sent: Tuesday, November 9, 2021 7:40:35 PM
To: Rodrigo Emmanuel Cordero 
Cc: pgsql-es-ay...@postgresql.org 
Subject: Re: Consulta sobre nodos master y replicas

On Tue, Nov 09, 2021 at 06:52:42PM +, Rodrigo Emmanuel Cordero wrote:
> Hola, antes que nada un gusto en saludarlos.
> Estoy teniendo una duda respecto al comportamiento del cluster con tres nodos 
> de postgres (1 Master / 2 Replicas).
> Cuando el nodo master se apaga, automáticamente uno de los nodos "replicas" 
> toma el control del master, esto esta bien.

en realidad, postgres no hace esto de forma automática. probablemente
tienes una aplicación que hace esto.

> Ahora la duda que tengo actualmente es cuando solo queda un solo nodo, el 
> único puerto al cual es posible conectarse es el 5000, y el 5001 pierde 
> conexión.
> ¿Este comportamiento es normal?
> ¿Teniendo un solo nodo activo, pueden quedar los puertos 5000 y 5001 activos 
> o esto ocurre solo cuando hay mas de un nodo activo?
>

y aqui se confirma el hecho de que tienes una aplicación haciendo esto.
esos puertos no los usa postgres para nada.

Sabes que estas usando para el failover? mi sospechas son haproxy o
pg_auto_failover

--
Jaime Casanova
Director de Servicios Profesionales
SystemGuards - Consultores de PostgreSQL


haproxy.cfg
Description: haproxy.cfg

Re: Consulta sobre nodos master y replicas

[Jaime Casanova]

On Tue, Nov 09, 2021 at 06:52:42PM +, Rodrigo Emmanuel Cordero wrote:
> Hola, antes que nada un gusto en saludarlos.
> Estoy teniendo una duda respecto al comportamiento del cluster con tres nodos 
> de postgres (1 Master / 2 Replicas).
> Cuando el nodo master se apaga, automáticamente uno de los nodos "replicas" 
> toma el control del master, esto esta bien.

en realidad, postgres no hace esto de forma automática. probablemente
tienes una aplicación que hace esto.

> Ahora la duda que tengo actualmente es cuando solo queda un solo nodo, el 
> único puerto al cual es posible conectarse es el 5000, y el 5001 pierde 
> conexión.
> ¿Este comportamiento es normal?
> ¿Teniendo un solo nodo activo, pueden quedar los puertos 5000 y 5001 activos 
> o esto ocurre solo cuando hay mas de un nodo activo?
> 

y aqui se confirma el hecho de que tienes una aplicación haciendo esto.
esos puertos no los usa postgres para nada.

Sabes que estas usando para el failover? mi sospechas son haproxy o
pg_auto_failover

-- 
Jaime Casanova
Director de Servicios Profesionales
SystemGuards - Consultores de PostgreSQL

Consulta sobre nodos master y replicas

[Rodrigo Emmanuel Cordero]

Hola, antes que nada un gusto en saludarlos.
Estoy teniendo una duda respecto al comportamiento del cluster con tres nodos 
de postgres (1 Master / 2 Replicas).
Cuando el nodo master se apaga, automáticamente uno de los nodos "replicas" 
toma el control del master, esto esta bien.
Ahora la duda que tengo actualmente es cuando solo queda un solo nodo, el único 
puerto al cual es posible conectarse es el 5000, y el 5001 pierde conexión.
¿Este comportamiento es normal?
¿Teniendo un solo nodo activo, pueden quedar los puertos 5000 y 5001 activos o 
esto ocurre solo cuando hay mas de un nodo activo?

Muchas gracias,

Rodrigo Cordero

Re: Consulta migracion2

[Carlos Joaniquet]

Buenas noches,

Prueba con una cadena conexión así:

*   Driver={PostgreSQL 
ANSI};Server=192.168.0.XX;Port=5432;Database=TuDb;Uid=<<_Usuario>>;Pwd=<<_Contraseña>>;

O con la versió 32 bits 12.02 a ver si te funciona

Saludos

Carlos Joaniquet Tamburini

> El 27 sept 2021, a las 17:58, ce...@cayter.com escribió:
> 
>  Buenos dias gente !
> Luego de las indicaciones recibidas, instale sin inconvenientes PosgreSQL 
> 13.4.1 sobre W10 Pro
> Creé la base de datos y restauré los registros tomados desde la version 9, 
> tengo acceso a los mismos desde Pgadmin, sin inconvenientes.
> Al ir a crear la conexion ODBC en la terminal (W7-32) con la version 9 del 
> ODBC, (en funcionamiento con el servidor que esta en producción) , vé al 
> servidor nuevo y conecta ok, pero al ir a configurar la conexión con las 
> tablas en la aplicación tira error de ODBC.
> No puedo instalar la version 13 de ODBc porque no está en 32
> Que sugerencias podrían darme, por favor ?
> 
> Gracias !
>  
> 
> 
> 
> 
> El 23/9/2021 a las 16:14, Alvaro Herrera escribió:
>> ce...@cayter.com escribió:
>>> Buenas tardes a todos, atiendo una pequeña empresa (con sus
>>> limitaciones...), que está utilizando PostgreSQL versión 9.2 , sobre W10
>>> pro, obviamente muy atrasados..., me piden la reinstalacion en una nueva PC
>>> con el mismo SO y la consulta es si puedo migrar las tablas tomando backup
>>> con pg_dump de la nueva version, digamos 13.4.1 y restaurarlas en la nueva
>>> instalación.
>> Sí, se supone que eso funciona bien.
>> 
>>> puedo tener problemas de incompatibilidad en la grabación y lectura de
>>> las mismas ?
>> No deberías tener ninguno.  Asegúrate de que han probado las
>> aplicaciones con Postgres 13, eso sí, porque puede haber
>> incompatibilidades ...
>> 
> 

Re: Consulta migracion

[Francisco Olarte]

Horacio:

On Fri, 24 Sept 2021 at 23:48, Horacio Miranda  wrote:
> No estoy de acuerdo con esto.
> Export de 9.2 usas el pg_dump del 9.2
> Import a 12, usas el pg_restore del 12.
> Yo no me arriesgo haciendo exports de datos usando bases remotas o con 
> versiones distintas.

Hay te estas arriesgando a no hacer lo que recomiendan los
desarrolladores, usar el del 12 para ambos.

>>>
18.6.1. Upgrading Data via pg_dumpall
...
It is recommended that you use the pg_dump and pg_dumpall programs
from the newer version of PostgreSQL, to take advantage of
enhancements that might have been made in these programs. Current
releases of the dump programs can read data from any server version
back to 7.0.
<<<

Entre otras cosa el pg_dump del 9.2 NO sabe que necesita el 12 en el
dump, la del 12 si, y lleva codigo para funcionar con servidores mas
antiguos, IIRC hasta la 8.0.

Puedes resolver en parte cosas con opciones de quoteo y similares,
pero por lo general lo mejor suele ser volcar con el pg_dump mas
nuevo.

FOS

Re: Consulta migracion

[Ivan Perales M.]

 Y que pasa si haces un pg_dump (en modo insert o copy) y luego importas
con un psql, es recomendable?

On Fri, Sep 24, 2021 at 6:21 PM Alvaro Herrera 
wrote:

> Horacio Miranda escribió:
> >
> > On 25/09/2021 3:00 am, Boriss Mejias wrote:
> > > Saludos Cesar,
> > >
> > > Un pequeña observación que a lo mejor ya sabes, pero nunca está demás
> > > repetirlo... nunca está demás repetirlo
> > >
> > > Cuando tomes el pg_dump, asegúrate que uses el pg_dump de la version
> 13,
> > > y no el pg_dump de la versión 9.2. Si no, podrías tener problemas al
> > > importar en la nueva versión.
> > >
> > No estoy de acuerdo con esto.
> >
> > Export de 9.2 usas el pg_dump del 9.2
> >
> > Import a 12, usas el pg_restore del 12.
>
> N NO HAGAS ESO, NO RECOMIENDES ESO!  Haz lo que te dijo Boriss, es
> lo mejor.  pg_dump es compatible hacia atrás.
>
> --
> Álvaro Herrera PostgreSQL Developer  —
> https://www.EnterpriseDB.com/
>
>
>

-- 
Lindolfo Iván Perales Mancinas
Solo existen 10 tipos de personas en el mundo, las que saben binario y las
que no.

Re: Consulta migracion

[Alvaro Herrera]

Horacio Miranda escribió:
> 
> On 25/09/2021 3:00 am, Boriss Mejias wrote:
> > Saludos Cesar,
> > 
> > Un pequeña observación que a lo mejor ya sabes, pero nunca está demás
> > repetirlo... nunca está demás repetirlo
> > 
> > Cuando tomes el pg_dump, asegúrate que uses el pg_dump de la version 13,
> > y no el pg_dump de la versión 9.2. Si no, podrías tener problemas al
> > importar en la nueva versión.
> > 
> No estoy de acuerdo con esto.
> 
> Export de 9.2 usas el pg_dump del 9.2
> 
> Import a 12, usas el pg_restore del 12.

N NO HAGAS ESO, NO RECOMIENDES ESO!  Haz lo que te dijo Boriss, es
lo mejor.  pg_dump es compatible hacia atrás.

-- 
Álvaro Herrera PostgreSQL Developer  —  https://www.EnterpriseDB.com/

Re: Consulta migracion

[Horacio Miranda]

On 25/09/2021 3:00 am, Boriss Mejias wrote:

Saludos Cesar,

Un pequeña observación que a lo mejor ya sabes, pero nunca está demás 
repetirlo... nunca está demás repetirlo


Cuando tomes el pg_dump, asegúrate que uses el pg_dump de la version 
13, y no el pg_dump de la versión 9.2. Si no, podrías tener problemas 
al importar en la nueva versión.



No estoy de acuerdo con esto.

Export de 9.2 usas el pg_dump del 9.2

Import a 12, usas el pg_restore del 12.

Yo no me arriesgo haciendo exports de datos usando bases remotas o con 
versiones distintas.



Saludos
Boriss

On Fri, 24 Sept 2021 at 08:30, Cesar > wrote:


Gracias por las respuestas, voy a verificar como trabaja la
aplicación, que fue realizada en vba 2000 …, veremos como se
comporta. Con respecto a tu consejo José, comparto, y así lo tengo
implementado desde siempre, la carpeta Data en otra particion, y
backapeada, permanentemente.

Sds.

César


El 23 sep. 2021, a la(s) 22:21, Jose Mercedes Venegas Acevedo
mailto:jvenegasp...@gmail.com>> escribió:


Hola Cesar
buen dia

yo uso postgres sobre windows vengo migrando desde la 8
actualmente voy en la 13 y todo bien vas a notar una excelente
mejora en la performance cuando migres eso lo note cuando subi a
la 10 esto que te comenta Alvaro

No deberías tener ninguno.  Asegúrate de que han probado las
aplicaciones con Postgres 13, eso sí, porque puede haber
incompatibilidades ...


Revisalo bien sobre todo si utilizas alguna aplicacion que no
gestiones tu directamente por ejemplo en mi caso uso un cliente
QGIS que me dio problemas con los campos identity inicialmente
que ya los resolvieron pero era un problema del lado de QGIS no
de postgres, un detalle adicional que comentarte es que en mi
experiencia no instales la carpeta data de postgres dentro de
archivos de programa en caso de algún desastre tener esa carpeta
fuera de ese directorio hace muy simple volver a levantar
postgres utilizando esa misma carpeta copiandola en otro lado
solo hay que asegurarse de tener la misma version precisa del
catalogo de postgres.

Saludos y éxitos con la migración.

José

Re: Consulta migracion

[Boriss Mejias]

Saludos Cesar,

Un pequeña observación que a lo mejor ya sabes, pero nunca está demás
repetirlo... nunca está demás repetirlo

Cuando tomes el pg_dump, asegúrate que uses el pg_dump de la version 13, y
no el pg_dump de la versión 9.2. Si no, podrías tener problemas al importar
en la nueva versión.

Saludos
Boriss

On Fri, 24 Sept 2021 at 08:30, Cesar  wrote:

> Gracias por las respuestas, voy a verificar como trabaja la aplicación,
> que fue realizada en vba 2000 …, veremos como se comporta. Con respecto a
> tu consejo José, comparto, y así lo tengo implementado desde siempre, la
> carpeta Data en otra particion, y backapeada, permanentemente.
>
> Sds.
>
> César
>
> El 23 sep. 2021, a la(s) 22:21, Jose Mercedes Venegas Acevedo <
> jvenegasp...@gmail.com> escribió:
>
> 
> Hola Cesar
> buen dia
>
> yo uso postgres sobre windows vengo migrando desde la 8 actualmente voy en
> la 13 y todo bien vas a notar una excelente mejora en la performance cuando
> migres eso lo note cuando subi a la 10 esto que te comenta Alvaro
>
>
>> No deberías tener ninguno.  Asegúrate de que han probado las
>> aplicaciones con Postgres 13, eso sí, porque puede haber
>> incompatibilidades ...
>
>
> Revisalo bien sobre todo si utilizas alguna aplicacion que no gestiones tu
> directamente por ejemplo en mi caso uso un cliente QGIS que me dio
> problemas con los campos identity inicialmente que ya los resolvieron pero
> era un problema del lado de QGIS no de postgres, un detalle adicional que
> comentarte es que en mi experiencia no instales la carpeta data de postgres
> dentro de archivos de programa en caso de algún desastre tener esa carpeta
> fuera de ese directorio hace muy simple volver a levantar postgres
> utilizando esa misma carpeta copiandola en otro lado solo hay que
> asegurarse de tener la misma version precisa del catalogo de postgres.
>
> Saludos y éxitos con la migración.
>
> José
>
>

Re: Consulta migracion

[Horacio Miranda]

On 24/09/2021 6:11 am, ce...@cayter.com wrote:
Buenas tardes a todos, atiendo una pequeña empresa (con sus 
limitaciones...), que está utilizando PostgreSQL versión 9.2 , sobre 
W10 pro, obviamente muy atrasados..., 

Estas para ayudarlos, no te preocupes.
me piden la reinstalacion en una nueva PC con el mismo SO 
S.O. Viejos son ideales para virtualizarlos, la idea es tener un motor 
virtual para que tome ventajas del hardware nuevo y el S.O. Virtual para 
correr cosas viejas (legacy).
y la consulta es si puedo migrar las tablas tomando backup con pg_dump 
de la nueva version, digamos 13.4.1 y restaurarlas en la nueva 
instalación.
Alvaro ya te respondio esta parte, deberia estar OK, revisa bien si usan 
algo particular y ojo con los cambios de pages, NLS langs.
puedo tener problemas de incompatibilidad en la grabación y lectura de 
las mismas ?


En mi experiencia las cosas que pasan son, cuando haces un export/import 
usando conversiones de lenguaje equivocadas es cuando hay problemas.


El software que se conecta a las bases de datos, revisa que tenga las 
librerias adecuadas, si lo que se conecta es Java, revisa que los jdbc 
sean los correctos, postgresql es super Robusto.




Gracias

Re: Consulta migracion

[Jose Mercedes Venegas Acevedo]

Hola Cesar
buen dia

yo uso postgres sobre windows vengo migrando desde la 8 actualmente voy en
la 13 y todo bien vas a notar una excelente mejora en la performance cuando
migres eso lo note cuando subi a la 10 esto que te comenta Alvaro


> No deberías tener ninguno.  Asegúrate de que han probado las
> aplicaciones con Postgres 13, eso sí, porque puede haber
> incompatibilidades ...


Revisalo bien sobre todo si utilizas alguna aplicacion que no gestiones tu
directamente por ejemplo en mi caso uso un cliente QGIS que me dio
problemas con los campos identity inicialmente que ya los resolvieron pero
era un problema del lado de QGIS no de postgres, un detalle adicional que
comentarte es que en mi experiencia no instales la carpeta data de postgres
dentro de archivos de programa en caso de algún desastre tener esa carpeta
fuera de ese directorio hace muy simple volver a levantar postgres
utilizando esa misma carpeta copiandola en otro lado solo hay que
asegurarse de tener la misma version precisa del catalogo de postgres.

Saludos y éxitos con la migración.

José

Re: Consulta migracion

[Alvaro Herrera]

ce...@cayter.com escribió:
> Buenas tardes a todos, atiendo una pequeña empresa (con sus
> limitaciones...), que está utilizando PostgreSQL versión 9.2 , sobre W10
> pro, obviamente muy atrasados..., me piden la reinstalacion en una nueva PC
> con el mismo SO y la consulta es si puedo migrar las tablas tomando backup
> con pg_dump de la nueva version, digamos 13.4.1 y restaurarlas en la nueva
> instalación.

Sí, se supone que eso funciona bien.

> puedo tener problemas de incompatibilidad en la grabación y lectura de
> las mismas ?

No deberías tener ninguno.  Asegúrate de que han probado las
aplicaciones con Postgres 13, eso sí, porque puede haber
incompatibilidades ...

-- 
Álvaro Herrera  Valdivia, Chile  —  https://www.EnterpriseDB.com/
"I can see support will not be a problem.  10 out of 10."(Simon Wittber)
  (http://archives.postgresql.org/pgsql-general/2004-12/msg00159.php)

Consulta sobre configuración de pgadmin

[PcOne Rosario]

En una consulta sobre una tabla con un campo texto de tipo varchar de más
de 256 caracteres, la salida de pgadmin me trunca los datos mostrados.
¿Cual puede ser el inconveniente?

-- 
PC One Informática & Redes
Zeballos 1980 - Tel. 0341-4253838
2000 - Rosario
Santa Fe - Argentina

Re: Consulta extract year

[Romero, Fernando]

?


De: Guillermo E. Villanueva 
Enviado: martes, 30 de marzo de 2021 12:27 p.m.
Para: Romero, Fernando
Cc: Alvaro Herrera; Jaime Casanova; pgsql-es-ay...@postgresql.org
Asunto: Re: Consulta extract year

Fijate que te da un valor exacto de cual es el problema, en la tabla 
"logpack_sheetorderhistory" id=231024, entonces estás tratando de borrar un 
"logpack_sheetitem" cuyo id 231024 es referenciado, independientemente del 
rango de fechas

Si Guillermo eso pasaba.
Gracias, saludos

El jue, 25 mar 2021 a las 13:12, Romero, Fernando (< 
fernando.rom...@trenesargentinos.gob.ar >) escribió:


-Mensaje original-
De: Alvaro Herrera [mailto: alvhe...@alvh.no-ip.org ]
Enviado el: jueves, 25 de marzo de 2021 12:52
Para: Romero, Fernando < fernando.rom...@trenesargentinos.gob.ar >
CC: Guillermo E. Villanueva < guillermo...@gmail.com >; Jaime Casanova < 
jcasa...@systemguards.com.ec >; pgsql-es-ay...@postgresql.org
Asunto: Re: Consulta extract year

Romero, Fernando escribió:
> Hola Guillemo gracias por tu respuesta.
> Ya lo resolvi, la tabla existe pero me tira ese esrror el extrac, lo resolvi 
> con otra query.
> Lo que tengo pendiente es borrar los registros, me da error el join
>
> => delete from logpack_orderstatehistory as a join
> logpack_sheetorderhistory as b on a.id = b.id where a.created BETWEEN
> '2018-01-01' AND '2018-12-31';
> ERROR:  syntax error at or near "join"
> LINE 2: join logpack_sheetorderhistory as b on a.id = b.id

> No encuentro la forma de poner ese join en el delete.

Me parece que lo que necesitas es

DELETE FROM logpack_sheetorderhistory USING logpack_sheetorderhistory WHERE ...


--
Álvaro Herrera   Valdivia, Chile
"Entristecido, Wutra (canción de Las Barreras)
echa a Freyr a rodar
y a nosotros al mar"


Si Alvaro necesitaba eso ya lo habia encontrado y lo corri pero me sigue dando 
error de foreign key la table que quiero borrar.
Si yo chequeo la tabla a la que ahce refencia ya no hay datos en ese rango pero 
cuando quiero borrar me sigue tira error de foreing key con el id

delete from logpack_sheetitem where created BETWEEN '2018-01-01' AND 
'2018-12-31';
ERROR:  update or delete on table "logpack_sheetitem" violates foreign key 
constraint "logpack_sheetorderhi_sheet_item_id_51c1456e_fk_logpack_s" on table 
"logpack_sheetorderhistory"
DETAIL:  Key (id)=(231024) is still referenced from table 
"logpack_sheetorderhistory".

Puede ser que la referencia este fuera del rango de fechas que quiero borrar?

Saludos
"El contenido del presente mensaje (y sus anexos) es privado, confidencial y de 
exclusivo uso para el destinatario referenciado; es de público conocimiento que 
las comunicaciones por medio de Internet no permiten asegurar ni garantizar la 
confidencialidad de los mensajes transmitidos, así como tampoco su integridad o 
su correcta recepción; es por ello que SOFSE no se responsabiliza de posibles 
perjuicios derivados de la captura, incorporaciones de virus o cualquier otra 
manipulación efectuada por terceros. Las opiniones expresadas en este mensaje y 
en los archivos adjuntos son propias del remitente y no representan la opinión 
o políticas de SOFSE, salvo que se diga expresamente y el remitente se 
encuentre autorizado para ello"
"El contenido del presente mensaje (y sus anexos) es privado, confidencial y de 
exclusivo uso para el destinatario referenciado; es de público conocimiento que 
las comunicaciones por medio de Internet no permiten asegurar ni garantizar la 
confidencialidad de los mensajes transmitidos, así como tampoco su integridad o 
su correcta recepción; es por ello que SOFSE no se responsabiliza de posibles 
perjuicios derivados de la captura, incorporaciones de virus o cualquier otra 
manipulación efectuada por terceros. Las opiniones expresadas en este mensaje y 
en los archivos adjuntos son propias del remitente y no representan la opinión 
o políticas de SOFSE, salvo que se diga expresamente y el remitente se 
encuentre autorizado para ello"

Re: Consulta extract year

[Guillermo E. Villanueva]

Fijate que te da un valor exacto de cual es el problema, en la tabla
"logpack_sheetorderhistory" id=231024, entonces estás tratando de borrar un
"logpack_sheetitem" cuyo id 231024 es referenciado, independientemente del
rango de fechas

El jue, 25 mar 2021 a las 13:12, Romero, Fernando (<
fernando.rom...@trenesargentinos.gob.ar>) escribió:

>
>
> -Mensaje original-
> De: Alvaro Herrera [mailto:alvhe...@alvh.no-ip.org]
> Enviado el: jueves, 25 de marzo de 2021 12:52
> Para: Romero, Fernando 
> CC: Guillermo E. Villanueva ; Jaime Casanova <
> jcasa...@systemguards.com.ec>; pgsql-es-ay...@postgresql.org
> Asunto: Re: Consulta extract year
>
> Romero, Fernando escribió:
> > Hola Guillemo gracias por tu respuesta.
> > Ya lo resolvi, la tabla existe pero me tira ese esrror el extrac, lo
> resolvi con otra query.
> > Lo que tengo pendiente es borrar los registros, me da error el join
> >
> > => delete from logpack_orderstatehistory as a join
> > logpack_sheetorderhistory as b on a.id = b.id where a.created BETWEEN
> > '2018-01-01' AND '2018-12-31';
> > ERROR:  syntax error at or near "join"
> > LINE 2: join logpack_sheetorderhistory as b on a.id = b.id
>
> > No encuentro la forma de poner ese join en el delete.
>
> Me parece que lo que necesitas es
>
> DELETE FROM logpack_sheetorderhistory USING logpack_sheetorderhistory
> WHERE ...
>
>
> --
> Álvaro Herrera   Valdivia, Chile
> "Entristecido, Wutra (canción de Las Barreras)
> echa a Freyr a rodar
> y a nosotros al mar"
>
>
> Si Alvaro necesitaba eso ya lo habia encontrado y lo corri pero me sigue
> dando error de foreign key la table que quiero borrar.
> Si yo chequeo la tabla a la que ahce refencia ya no hay datos en ese rango
> pero cuando quiero borrar me sigue tira error de foreing key con el id
>
> delete from logpack_sheetitem where created BETWEEN '2018-01-01' AND
> '2018-12-31';
> ERROR:  update or delete on table "logpack_sheetitem" violates foreign key
> constraint "logpack_sheetorderhi_sheet_item_id_51c1456e_fk_logpack_s" on
> table "logpack_sheetorderhistory"
> DETAIL:  Key (id)=(231024) is still referenced from table
> "logpack_sheetorderhistory".
>
> Puede ser que la referencia este fuera del rango de fechas que quiero
> borrar?
>
> Saludos
> “El contenido del presente mensaje (y sus anexos) es privado, confidencial
> y de exclusivo uso para el destinatario referenciado; es de público
> conocimiento que las comunicaciones por medio de Internet no permiten
> asegurar ni garantizar la confidencialidad de los mensajes transmitidos,
> así como tampoco su integridad o su correcta recepción; es por ello que
> SOFSE no se responsabiliza de posibles perjuicios derivados de la captura,
> incorporaciones de virus o cualquier otra manipulación efectuada por
> terceros. Las opiniones expresadas en este mensaje y en los archivos
> adjuntos son propias del remitente y no representan la opinión o políticas
> de SOFSE, salvo que se diga expresamente y el remitente se encuentre
> autorizado para ello”
>

RE: Consulta extract year

[Romero, Fernando]

-Mensaje original-
De: Alvaro Herrera [mailto:alvhe...@alvh.no-ip.org]
Enviado el: jueves, 25 de marzo de 2021 12:52
Para: Romero, Fernando 
CC: Guillermo E. Villanueva ; Jaime Casanova 
; pgsql-es-ay...@postgresql.org
Asunto: Re: Consulta extract year

Romero, Fernando escribió:
> Hola Guillemo gracias por tu respuesta.
> Ya lo resolvi, la tabla existe pero me tira ese esrror el extrac, lo resolvi 
> con otra query.
> Lo que tengo pendiente es borrar los registros, me da error el join
>
> => delete from logpack_orderstatehistory as a join
> logpack_sheetorderhistory as b on a.id = b.id where a.created BETWEEN
> '2018-01-01' AND '2018-12-31';
> ERROR:  syntax error at or near "join"
> LINE 2: join logpack_sheetorderhistory as b on a.id = b.id

> No encuentro la forma de poner ese join en el delete.

Me parece que lo que necesitas es

DELETE FROM logpack_sheetorderhistory USING logpack_sheetorderhistory WHERE ...


--
Álvaro Herrera   Valdivia, Chile
"Entristecido, Wutra (canción de Las Barreras)
echa a Freyr a rodar
y a nosotros al mar"


Si Alvaro necesitaba eso ya lo habia encontrado y lo corri pero me sigue dando 
error de foreign key la table que quiero borrar.
Si yo chequeo la tabla a la que ahce refencia ya no hay datos en ese rango pero 
cuando quiero borrar me sigue tira error de foreing key con el id

delete from logpack_sheetitem where created BETWEEN '2018-01-01' AND 
'2018-12-31';
ERROR:  update or delete on table "logpack_sheetitem" violates foreign key 
constraint "logpack_sheetorderhi_sheet_item_id_51c1456e_fk_logpack_s" on table 
"logpack_sheetorderhistory"
DETAIL:  Key (id)=(231024) is still referenced from table 
"logpack_sheetorderhistory".

Puede ser que la referencia este fuera del rango de fechas que quiero borrar?

Saludos
“El contenido del presente mensaje (y sus anexos) es privado, confidencial y de 
exclusivo uso para el destinatario referenciado; es de público conocimiento que 
las comunicaciones por medio de Internet no permiten asegurar ni garantizar la 
confidencialidad de los mensajes transmitidos, así como tampoco su integridad o 
su correcta recepción; es por ello que SOFSE no se responsabiliza de posibles 
perjuicios derivados de la captura, incorporaciones de virus o cualquier otra 
manipulación efectuada por terceros. Las opiniones expresadas en este mensaje y 
en los archivos adjuntos son propias del remitente y no representan la opinión 
o políticas de SOFSE, salvo que se diga expresamente y el remitente se 
encuentre autorizado para ello”

Re: Consulta extract year

[Alvaro Herrera]

Romero, Fernando escribió:
> Hola Guillemo gracias por tu respuesta.
> Ya lo resolvi, la tabla existe pero me tira ese esrror el extrac, lo resolvi 
> con otra query.
> Lo que tengo pendiente es borrar los registros, me da error el join
> 
> => delete from logpack_orderstatehistory as a
> join logpack_sheetorderhistory as b on a.id = b.id
> where a.created BETWEEN '2018-01-01' AND '2018-12-31';
> ERROR:  syntax error at or near "join"
> LINE 2: join logpack_sheetorderhistory as b on a.id = b.id

> No encuentro la forma de poner ese join en el delete.

Me parece que lo que necesitas es

DELETE FROM logpack_sheetorderhistory USING logpack_sheetorderhistory
WHERE ...


-- 
Álvaro Herrera   Valdivia, Chile
"Entristecido, Wutra (canción de Las Barreras)
echa a Freyr a rodar
y a nosotros al mar"

RE: Consulta extract year

[Romero, Fernando]

Hola Guillemo gracias por tu respuesta.
Ya lo resolvi, la tabla existe pero me tira ese esrror el extrac, lo resolvi 
con otra query.
Lo que tengo pendiente es borrar los registros, me da error el join

=> delete from logpack_orderstatehistory as a
join logpack_sheetorderhistory as b on a.id = b.id
where a.created BETWEEN '2018-01-01' AND '2018-12-31';
ERROR:  syntax error at or near "join"
LINE 2: join logpack_sheetorderhistory as b on a.id = b.id

No encuentro la forma de poner ese join en el delete.

Saludos


De: Guillermo E. Villanueva [mailto:guillermo...@gmail.com]
Enviado el: miércoles, 24 de marzo de 2021 22:18
Para: Romero, Fernando 
CC: Jaime Casanova ; pgsql-es-ay...@postgresql.org
Asunto: Re: Consulta extract year

Probá con el select que te mandó Jaime y contanos que te devuelve:
select schemaname, relname from pg_stat_user_tables where relname = 'tabla';

El mié, 24 mar 2021 a las 9:57, Romero, Fernando (< 
fernando.rom...@trenesargentinos.gob.ar<mailto:fernando.rom...@trenesargentinos.gob.ar>
 >) escribió:


-Mensaje original-
De: Jaime Casanova [mailto: 
jcasa...@systemguards.com.ec<mailto:jcasa...@systemguards.com.ec> ]
Enviado el: miércoles, 24 de marzo de 2021 03:52
Para: Romero, Fernando < 
fernando.rom...@trenesargentinos.gob.ar<mailto:fernando.rom...@trenesargentinos.gob.ar>
 >
CC: pgsql-es-ay...@postgresql.org<mailto:pgsql-es-ay...@postgresql.org>
Asunto: Re: Consulta extract year

On Tue, Mar 23, 2021 at 6:37 PM Romero, Fernando < 
fernando.rom...@trenesargentinos.gob.ar<mailto:fernando.rom...@trenesargentinos.gob.ar>
 > wrote:
>
> Hola como estan, tengo un error en un select con extract para
> consultar fecha por año, quiero un campo con los datos de todo el año
> 2018 y la consulta del select es esta
>
> select campo from tabla where extract('year' from created)=2018; (donde 
> created es el campo fecha de la table) y me da este error:
>
> ERROR:  relation "tabla" does not exist LINE 1: select campo from
> tabla where extract('year'...
>

Ah! y la tabla "tabla", si existe? porque el mensaje de error dice que no.
puedes mostrar la salida de;

select schemaname, relname from pg_stat_user_tables where relname = 'tabla';

>
> Si hago un delete me funciona.
>
> delete from tabla where extract('year' from created)=2018;
>

en serio? con el mismo nombre de tabla?
con el mismo usuario?

--
Jaime Casanova
Director de Servicios Profesionales
SYSTEMGUARDS - Consultores de PostgreSQL

Hola Jaime gracias por tu respuesta si la table existe y cuando hago el delete 
no me tira el error que no existe.

Saludos
“El contenido del presente mensaje (y sus anexos) es privado, confidencial y de 
exclusivo uso para el destinatario referenciado; es de público conocimiento que 
las comunicaciones por medio de Internet no permiten asegurar ni garantizar la 
confidencialidad de los mensajes transmitidos, así como tampoco su integridad o 
su correcta recepción; es por ello que SOFSE no se responsabiliza de posibles 
perjuicios derivados de la captura, incorporaciones de virus o cualquier otra 
manipulación efectuada por terceros. Las opiniones expresadas en este mensaje y 
en los archivos adjuntos son propias del remitente y no representan la opinión 
o políticas de SOFSE, salvo que se diga expresamente y el remitente se 
encuentre autorizado para ello”
“El contenido del presente mensaje (y sus anexos) es privado, confidencial y de 
exclusivo uso para el destinatario referenciado; es de público conocimiento que 
las comunicaciones por medio de Internet no permiten asegurar ni garantizar la 
confidencialidad de los mensajes transmitidos, así como tampoco su integridad o 
su correcta recepción; es por ello que SOFSE no se responsabiliza de posibles 
perjuicios derivados de la captura, incorporaciones de virus o cualquier otra 
manipulación efectuada por terceros. Las opiniones expresadas en este mensaje y 
en los archivos adjuntos son propias del remitente y no representan la opinión 
o políticas de SOFSE, salvo que se diga expresamente y el remitente se 
encuentre autorizado para ello”

Re: Consulta extract year

[Guillermo E. Villanueva]

Probá con el select que te mandó Jaime y contanos que te devuelve:
select schemaname, relname from pg_stat_user_tables where relname = 'tabla';

El mié, 24 mar 2021 a las 9:57, Romero, Fernando (<
fernando.rom...@trenesargentinos.gob.ar>) escribió:

>
>
> -Mensaje original-
> De: Jaime Casanova [mailto:jcasa...@systemguards.com.ec]
> Enviado el: miércoles, 24 de marzo de 2021 03:52
> Para: Romero, Fernando 
> CC: pgsql-es-ay...@postgresql.org
> Asunto: Re: Consulta extract year
>
> On Tue, Mar 23, 2021 at 6:37 PM Romero, Fernando <
> fernando.rom...@trenesargentinos.gob.ar> wrote:
> >
> > Hola como estan, tengo un error en un select con extract para
> > consultar fecha por año, quiero un campo con los datos de todo el año
> > 2018 y la consulta del select es esta
> >
> > select campo from tabla where extract('year' from created)=2018; (donde
> created es el campo fecha de la table) y me da este error:
> >
> > ERROR:  relation "tabla" does not exist LINE 1: select campo from
> > tabla where extract('year'...
> >
>
> Ah! y la tabla "tabla", si existe? porque el mensaje de error dice que no.
> puedes mostrar la salida de;
>
> select schemaname, relname from pg_stat_user_tables where relname =
> 'tabla';
>
> >
> > Si hago un delete me funciona.
> >
> > delete from tabla where extract('year' from created)=2018;
> >
>
> en serio? con el mismo nombre de tabla?
> con el mismo usuario?
>
> --
> Jaime Casanova
> Director de Servicios Profesionales
> SYSTEMGUARDS - Consultores de PostgreSQL
>
> Hola Jaime gracias por tu respuesta si la table existe y cuando hago el
> delete no me tira el error que no existe.
>
> Saludos
> “El contenido del presente mensaje (y sus anexos) es privado, confidencial
> y de exclusivo uso para el destinatario referenciado; es de público
> conocimiento que las comunicaciones por medio de Internet no permiten
> asegurar ni garantizar la confidencialidad de los mensajes transmitidos,
> así como tampoco su integridad o su correcta recepción; es por ello que
> SOFSE no se responsabiliza de posibles perjuicios derivados de la captura,
> incorporaciones de virus o cualquier otra manipulación efectuada por
> terceros. Las opiniones expresadas en este mensaje y en los archivos
> adjuntos son propias del remitente y no representan la opinión o políticas
> de SOFSE, salvo que se diga expresamente y el remitente se encuentre
> autorizado para ello”
>

RE: Consulta foreign key

[Romero, Fernando]

De: Hellmuth Vargas [mailto:hiv...@gmail.com]
Enviado el: miércoles, 24 de marzo de 2021 10:47
Para: Romero, Fernando 
CC: Jaime Casanova ; pgsql-es-ay...@postgresql.org
Asunto: Re: Consulta foreign key

Hola Fernando

Jaime ahi estuve mirando mas a detalle, tiene relaciones que no están dentro 
del rango de fecha que quiero eliminar, tendría que deshabilitar la foreign key?

Pues supongo que el foreign esta garantizado la consistencia de la información: 
 si esta "brincando" es porque  hay información  relacionada (si esta bien 
implementado) , una suposición, es que la tabla logpack_sheetorderhistory es un 
histórico que puede tener movimientos  anteriores al rango de fechas  que se 
pretende  eliminar en la tabla logpack_orderstatehistory

Debería sacar los registros relacionadas entre las tablas y construir el delete 
 basándose  en la clave primaria/clave foránea más  bien:

La consulta sugerida seria algo como:


select a.* from logpack_orderstatehistory as a
join logpack_sheetorderhistory as b on a.id = b.id   -- supongo que la columna 
relacionada en logpack_sheetorderhistory es id
where a.created BETWEEN '2019-01-01' AND '2019-12-31'


--
Cordialmente,

Ing. Hellmuth I. Vargas S.

Gracias por tu respuesta, esa consulta me devolvió los registros.
Esos registros tendría que borrar para que después me deje eliminar los 
registros de la tabla anterior no?
Saludos
“El contenido del presente mensaje (y sus anexos) es privado, confidencial y de 
exclusivo uso para el destinatario referenciado; es de público conocimiento que 
las comunicaciones por medio de Internet no permiten asegurar ni garantizar la 
confidencialidad de los mensajes transmitidos, así como tampoco su integridad o 
su correcta recepción; es por ello que SOFSE no se responsabiliza de posibles 
perjuicios derivados de la captura, incorporaciones de virus o cualquier otra 
manipulación efectuada por terceros. Las opiniones expresadas en este mensaje y 
en los archivos adjuntos son propias del remitente y no representan la opinión 
o políticas de SOFSE, salvo que se diga expresamente y el remitente se 
encuentre autorizado para ello”

Re: Consulta foreign key

[Hellmuth Vargas]

Hola Fernando

Jaime ahi estuve mirando mas a detalle, tiene relaciones que no están
> dentro del rango de fecha que quiero eliminar, tendría que deshabilitar la
> foreign key?
>

Pues supongo que el foreign esta garantizado la consistencia de la
información:  si esta "brincando" es porque  hay información  relacionada
(si esta bien implementado) , una suposición, es que la tabla
logpack_sheetorderhistory es un histórico que puede tener movimientos
anteriores al rango de fechas  que se pretende  eliminar en la tabla
logpack_orderstatehistory

Debería sacar los registros relacionadas entre las tablas y construir el
delete  basándose  en la clave primaria/clave foránea más  bien:

La consulta sugerida seria algo como:


select a.* from logpack_orderstatehistory as a
join logpack_sheetorderhistory as b on a.id=b.id  -- supongo que la columna
relacionada en logpack_sheetorderhistory es id
where a.created BETWEEN '2019-01-01' AND '2019-12-31'


-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.

RE: Consulta foreign key

[Romero, Fernando]

-Mensaje original-
De: Jaime Casanova [mailto:jcasa...@systemguards.com.ec]
Enviado el: miércoles, 24 de marzo de 2021 03:26
Para: Romero, Fernando 
CC: pgsql-es-ay...@postgresql.org
Asunto: Re: Consulta foreign key

On Tue, Mar 23, 2021 at 10:03 PM Romero, Fernando 
 wrote:
>
> Si chequeo el campo id al que hace referencia en ese rango de fechas
> no tiene datos
>
> select id from logpack_sheetorderhistory where created BETWEEN
> '2019-01-01' AND '2019-12-31';
>

Lo  que deberías estar chequeando es:

SELECT * FROM logpack_sheetorderhistory WHERE id = 14470448;

Es muy probable que simplemente ese registro no esté en el mismo rango de 
fechas.

Ahora, pensando un poco más allá, el problema podría ser el tipo de dato. Si 
created es un timestamp el rango de fechas que estas usando se completa así: 
BETWEEN '2019-01-01 00:00:00' AND '2019-12-31 00:00:00'.
Es decir, la fecha automáticamente completa las horas a la medianoche así que 
tu criterio de busqueda debería ser: BETWEEN '2019-01-01' AND
'2019-12-31 23:59.59.99'

--
Jaime Casanova
Director de Servicios Profesionales
SYSTEMGUARDS - Consultores de PostgreSQL

Jaime ahi estuve mirando mas a detalle, tiene relaciones que no están dentro 
del rango de fecha que quiero eliminar, tendría que deshabilitar la foreign key?

Saludos
“El contenido del presente mensaje (y sus anexos) es privado, confidencial y de 
exclusivo uso para el destinatario referenciado; es de público conocimiento que 
las comunicaciones por medio de Internet no permiten asegurar ni garantizar la 
confidencialidad de los mensajes transmitidos, así como tampoco su integridad o 
su correcta recepción; es por ello que SOFSE no se responsabiliza de posibles 
perjuicios derivados de la captura, incorporaciones de virus o cualquier otra 
manipulación efectuada por terceros. Las opiniones expresadas en este mensaje y 
en los archivos adjuntos son propias del remitente y no representan la opinión 
o políticas de SOFSE, salvo que se diga expresamente y el remitente se 
encuentre autorizado para ello”

RE: Consulta foreign key

[Romero, Fernando]

-Mensaje original-
De: Jaime Casanova [mailto:jcasa...@systemguards.com.ec]
Enviado el: miércoles, 24 de marzo de 2021 03:26
Para: Romero, Fernando 
CC: pgsql-es-ay...@postgresql.org
Asunto: Re: Consulta foreign key

On Tue, Mar 23, 2021 at 10:03 PM Romero, Fernando 
 wrote:
>
> Si chequeo el campo id al que hace referencia en ese rango de fechas
> no tiene datos
>
> select id from logpack_sheetorderhistory where created BETWEEN
> '2019-01-01' AND '2019-12-31';
>

Lo  que deberías estar chequeando es:

SELECT * FROM logpack_sheetorderhistory WHERE id = 14470448;

Es muy probable que simplemente ese registro no esté en el mismo rango de 
fechas.

Ahora, pensando un poco más allá, el problema podría ser el tipo de dato. Si 
created es un timestamp el rango de fechas que estas usando se completa así: 
BETWEEN '2019-01-01 00:00:00' AND '2019-12-31 00:00:00'.
Es decir, la fecha automáticamente completa las horas a la medianoche así que 
tu criterio de busqueda debería ser: BETWEEN '2019-01-01' AND
'2019-12-31 23:59.59.99'

--
Jaime Casanova
Director de Servicios Profesionales
SYSTEMGUARDS - Consultores de PostgreSQL

Antes me habia tira otro error con otro id, borre ese id y cuando borro el id 
que me da error me vuelve a tirar otro y el id que me tira no esta en el rango 
de fecha que quiero borrar

Saludos
“El contenido del presente mensaje (y sus anexos) es privado, confidencial y de 
exclusivo uso para el destinatario referenciado; es de público conocimiento que 
las comunicaciones por medio de Internet no permiten asegurar ni garantizar la 
confidencialidad de los mensajes transmitidos, así como tampoco su integridad o 
su correcta recepción; es por ello que SOFSE no se responsabiliza de posibles 
perjuicios derivados de la captura, incorporaciones de virus o cualquier otra 
manipulación efectuada por terceros. Las opiniones expresadas en este mensaje y 
en los archivos adjuntos son propias del remitente y no representan la opinión 
o políticas de SOFSE, salvo que se diga expresamente y el remitente se 
encuentre autorizado para ello”

RE: Consulta extract year

[Romero, Fernando]

-Mensaje original-
De: Jaime Casanova [mailto:jcasa...@systemguards.com.ec]
Enviado el: miércoles, 24 de marzo de 2021 03:52
Para: Romero, Fernando 
CC: pgsql-es-ay...@postgresql.org
Asunto: Re: Consulta extract year

On Tue, Mar 23, 2021 at 6:37 PM Romero, Fernando 
 wrote:
>
> Hola como estan, tengo un error en un select con extract para
> consultar fecha por año, quiero un campo con los datos de todo el año
> 2018 y la consulta del select es esta
>
> select campo from tabla where extract('year' from created)=2018; (donde 
> created es el campo fecha de la table) y me da este error:
>
> ERROR:  relation "tabla" does not exist LINE 1: select campo from
> tabla where extract('year'...
>

Ah! y la tabla "tabla", si existe? porque el mensaje de error dice que no.
puedes mostrar la salida de;

select schemaname, relname from pg_stat_user_tables where relname = 'tabla';

>
> Si hago un delete me funciona.
>
> delete from tabla where extract('year' from created)=2018;
>

en serio? con el mismo nombre de tabla?
con el mismo usuario?

--
Jaime Casanova
Director de Servicios Profesionales
SYSTEMGUARDS - Consultores de PostgreSQL

Hola Jaime gracias por tu respuesta si la table existe y cuando hago el delete 
no me tira el error que no existe.

Saludos
“El contenido del presente mensaje (y sus anexos) es privado, confidencial y de 
exclusivo uso para el destinatario referenciado; es de público conocimiento que 
las comunicaciones por medio de Internet no permiten asegurar ni garantizar la 
confidencialidad de los mensajes transmitidos, así como tampoco su integridad o 
su correcta recepción; es por ello que SOFSE no se responsabiliza de posibles 
perjuicios derivados de la captura, incorporaciones de virus o cualquier otra 
manipulación efectuada por terceros. Las opiniones expresadas en este mensaje y 
en los archivos adjuntos son propias del remitente y no representan la opinión 
o políticas de SOFSE, salvo que se diga expresamente y el remitente se 
encuentre autorizado para ello”

Re: Consulta extract year

[Jaime Casanova]

On Tue, Mar 23, 2021 at 6:37 PM Romero, Fernando
 wrote:
>
> Hola como estan, tengo un error en un select con extract para consultar fecha 
> por año, quiero un campo con los datos de todo el año 2018 y la consulta del 
> select es esta
>
> select campo from tabla where extract('year' from created)=2018; (donde 
> created es el campo fecha de la table) y me da este error:
>
> ERROR:  relation "tabla" does not exist
> LINE 1: select campo from tabla where extract('year'...
>

Ah! y la tabla "tabla", si existe? porque el mensaje de error dice que no.
puedes mostrar la salida de;

select schemaname, relname from pg_stat_user_tables where relname = 'tabla';

>
> Si hago un delete me funciona.
>
> delete from tabla where extract('year' from created)=2018;
>

en serio? con el mismo nombre de tabla?
con el mismo usuario?

-- 
Jaime Casanova
Director de Servicios Profesionales
SYSTEMGUARDS - Consultores de PostgreSQL

Re: Consulta foreign key

[Jaime Casanova]

On Tue, Mar 23, 2021 at 10:03 PM Romero, Fernando
 wrote:
>
> Si chequeo el campo id al que hace referencia en ese rango de fechas no tiene 
> datos
>
> select id from logpack_sheetorderhistory where created BETWEEN '2019-01-01' 
> AND '2019-12-31';
>

Lo  que deberías estar chequeando es:

SELECT * FROM logpack_sheetorderhistory WHERE id = 14470448;

Es muy probable que simplemente ese registro no esté en el mismo rango
de fechas.

Ahora, pensando un poco más allá, el problema podría ser el tipo de
dato. Si created es un timestamp el rango de fechas que estas usando
se completa así: BETWEEN '2019-01-01 00:00:00' AND '2019-12-31
00:00:00'.
Es decir, la fecha automáticamente completa las horas a la medianoche
así que tu criterio de busqueda debería ser: BETWEEN '2019-01-01' AND
'2019-12-31 23:59.59.99'

-- 
Jaime Casanova
Director de Servicios Profesionales
SYSTEMGUARDS - Consultores de PostgreSQL

Consulta foreign key

[Romero, Fernando]

Hola como estan, consulto por un tema de foreign key ya que algo se me esta 
escapando.
Estoy borrado una tabla entre fecha me tiro violacion de contrainst porque hace 
referencia a otra tabla, fui a esa tabla y borre las misma fecha, cuando vuelvo 
a la tabla me vuelve a tirar error deviolacion de constraints con otro id.

=> delete from logpack_orderstatehistory where created BETWEEN '2019-01-01' AND 
'2019-12-31';
ERROR:  update or delete on table "logpack_orderstatehistory" violates foreign 
key constraint 
"logpack_sheetorderhi_order_state_history__dfe8dbe1_fk_logpack_o" on table 
"logpack_sheetorderhistory"
DETAIL:  Key (id)=(13388177) is still referenced from table 
"logpack_sheetorderhistory".
=> delete from logpack_sheetorderhistory where created BETWEEN '2019-01-01' AND 
'2019-12-31';
DELETE 6557673
=> delete from logpack_orderstatehistory where created BETWEEN '2019-01-01' AND 
'2019-12-31';
ERROR:  update or delete on table "logpack_orderstatehistory" violates foreign 
key constraint 
"logpack_sheetorderhi_order_state_history__dfe8dbe1_fk_logpack_o" on table 
"logpack_sheetorderhistory"
DETAIL:  Key (id)=(14470448) is still referenced from table 
"logpack_sheetorderhistory".

Si chequeo el campo id al que hace referencia en ese rango de fechas no tiene 
datos
select id from logpack_sheetorderhistory where created BETWEEN '2019-01-01' AND 
'2019-12-31';
id

(0 rows)

Que error estoy cometiendo?

Saludos y gracias


"El contenido del presente mensaje (y sus anexos) es privado, confidencial y de 
exclusivo uso para el destinatario referenciado; es de p?blico conocimiento que 
las comunicaciones por medio de Internet no permiten asegurar ni garantizar la 
confidencialidad de los mensajes transmitidos, as? como tampoco su integridad o 
su correcta recepci?n; es por ello que SOFSE no se responsabiliza de posibles 
perjuicios derivados de la captura, incorporaciones de virus o cualquier otra 
manipulaci?n efectuada por terceros. Las opiniones expresadas en este mensaje y 
en los archivos adjuntos son propias del remitente y no representan la opini?n 
o pol?ticas de SOFSE, salvo que se diga expresamente y el remitente se 
encuentre autorizado para ello"

Consulta extract year

[Romero, Fernando]

Hola como estan, tengo un error en un select con extract para consultar fecha 
por año, quiero un campo con los datos de todo el año 2018 y la consulta del 
select es esta

select campo from tabla where extract('year' from created)=2018; (donde created 
es el campo fecha de la table) y me da este error:

ERROR:  relation "tabla" does not exist
LINE 1: select campo from tabla where extract('year'...

Si hago un delete me funciona.

delete from tabla where extract('year' from created)=2018;

Saludos
"El contenido del presente mensaje (y sus anexos) es privado, confidencial y de 
exclusivo uso para el destinatario referenciado; es de público conocimiento que 
las comunicaciones por medio de Internet no permiten asegurar ni garantizar la 
confidencialidad de los mensajes transmitidos, así como tampoco su integridad o 
su correcta recepción; es por ello que SOFSE no se responsabiliza de posibles 
perjuicios derivados de la captura, incorporaciones de virus o cualquier otra 
manipulación efectuada por terceros. Las opiniones expresadas en este mensaje y 
en los archivos adjuntos son propias del remitente y no representan la opinión 
o políticas de SOFSE, salvo que se diga expresamente y el remitente se 
encuentre autorizado para ello"

Re: Consulta borrar registros en cascada

[Alvaro Herrera]

Romero, Fernando escribió:
> Hola como estan, mi consulta es la siguiente...
> Puedo borrar registros por año? estoy intentando y me da error, vengo
> de mysql y ahí con la opción "where year(tabla)=año" borro todo ese
> año.

Obvio, pero la sintaxis puede ser diferente.  Quizás
"where extract('year' from tabla)"

... suponiendo que tu columna con fechas se llame "tabla", que me parece
algo absurdo, pero tu ejemplo es así ...

Es buena idea mostrar qué error da.

-- 
Álvaro Herrera   Valdivia, Chile
"El miedo atento y previsor es la madre de la seguridad" (E. Burke)

Re: Consulta borrar registros en cascada

[Marcelo Diaz]

Fernando,

Cuando se eliminan registros en PostgreSQL, es importante tener en cuenta
las foreign keys que pueden existir entre estos registros y los registros
de una tabla diferente. Para ello, la opción  DELETE ON CASCADE ayuda a
garantizar que todos los registros hijos también se eliminen cuando se
elimina un registro padre.

Aquí te dejo un ejemplo:

create table secciones
(
   seccion_id serial primary key,
   nombre text
);

create table empleados
(
   empleado_id serial,
   seccion_id int,
   primary key (empleado_id, seccion_id),
   *constraint fk_seccion foreign key (seccion_id) *
*   references secciones(seccion_id) on delete cascade*
);

insert into secciones (nombre) values ('Contabilidad'), ('RRHH'),
('Servicio');

insert into empleados values (1, 1), (2,1), (3,2), (4,3);

select * from empleados;
 empleado_id | seccion_id
-+
   1 |  1
   2 |  1
   3 |  2
   4 |  3

delete from secciones where seccion_id = 2;

select * from empleados;
 empleado_id | seccion_id
-+
   1 |  1
   2 |  1
   4 |  3
Como puedes ver se borro la seccion 2 y tambien el empleado de esa seccion.
https://www.postgresql.org/docs/current/ddl-constraints.html

Espero sirva.

Saludos.
















 Marcelo Diaz




On Thu, Feb 25, 2021 at 11:05 AM Romero, Fernando <
fernando.rom...@trenesargentinos.gob.ar> wrote:

> Hola como estan, mi consulta es la siguiente…
>
> Puedo borrar registros por año? estoy intentando y me da error, vengo de
> mysql y ahí con la opción “where year(tabla)=año” borro todo ese año.
>
> Para borrar en cascada o sea que borre también en las tablas referenciadas
> con la opción delete on cascade?.
>
>
>
> Saludos y gracias
>
> “El contenido del presente mensaje (y sus anexos) es privado, confidencial
> y de exclusivo uso para el destinatario referenciado; es de público
> conocimiento que las comunicaciones por medio de Internet no permiten
> asegurar ni garantizar la confidencialidad de los mensajes transmitidos,
> así como tampoco su integridad o su correcta recepción; es por ello que
> SOFSE no se responsabiliza de posibles perjuicios derivados de la captura,
> incorporaciones de virus o cualquier otra manipulación efectuada por
> terceros. Las opiniones expresadas en este mensaje y en los archivos
> adjuntos son propias del remitente y no representan la opinión o políticas
> de SOFSE, salvo que se diga expresamente y el remitente se encuentre
> autorizado para ello”
>

Consulta borrar registros en cascada

[Romero, Fernando]

Hola como estan, mi consulta es la siguiente...
Puedo borrar registros por año? estoy intentando y me da error, vengo de mysql 
y ahí con la opción "where year(tabla)=año" borro todo ese año.
Para borrar en cascada o sea que borre también en las tablas referenciadas con 
la opción delete on cascade?.

Saludos y gracias
"El contenido del presente mensaje (y sus anexos) es privado, confidencial y de 
exclusivo uso para el destinatario referenciado; es de público conocimiento que 
las comunicaciones por medio de Internet no permiten asegurar ni garantizar la 
confidencialidad de los mensajes transmitidos, así como tampoco su integridad o 
su correcta recepción; es por ello que SOFSE no se responsabiliza de posibles 
perjuicios derivados de la captura, incorporaciones de virus o cualquier otra 
manipulación efectuada por terceros. Las opiniones expresadas en este mensaje y 
en los archivos adjuntos son propias del remitente y no representan la opinión 
o políticas de SOFSE, salvo que se diga expresamente y el remitente se 
encuentre autorizado para ello"

Re: Consulta

[Horacio Miranda]

On 24/02/2021 6:50 am, Carlos Edward Grajales Marmolejo wrote:


Hola buen dia.

Tengo la siguiente consulta.
Existe algun mecanismo con el que se pueda generar logs de la cantidad 
de trafico de red de entrada y/o salida que genera una base de datos 
en postgres?, me interesa optimizar aquellas consultas que generen 
mucho trafico de salida, claro siempre que se pueda.


Al momento he optimizado la base datos desde los siguientes puntos de 
vista:

1. Consultas Lentas
2. Cantidad de registros devueltos por consultas.
3. Consultas repetitivas (uso de cache)

Activa las consultas lentas en los logs, las que mueven mucho trafico se 
van a demorar mucho.
Y ya estoy usando herramientas como pgbadger y pg_stat_statements para 
hacer analisis, que mas podria usar para buscar optimizaciones, y en 
particular medir el trafico de red?


Pegale una mirada a alguna que recomiende indices ( en lo personal me 
gustan los reportes de indices para crear, no activarlas para que hagan 
lo que quieran estas erramientas.


Sobre la red, lo unico que se me ocurre es que instales algo como 
observium y captures los traficos de salida por IP, revises las que IP 
que trafican mucho y cruzando esa información con las consultas lentas 
de pueden salir algunas que esten traficando mucho.


Ahora algo que hago en Oracle es consultas largas. postgresql tiene algo 
similar tambien.

https://til.codes/finding-long-running-sql-queries-in-postgresql/



Gracias por su ayuda.

Consulta

[Carlos Edward Grajales Marmolejo]

Hola buen dia.

Tengo la siguiente consulta.
Existe algun mecanismo con el que se pueda generar logs de la cantidad de
trafico de red de entrada y/o salida que genera una base de datos en
postgres?, me interesa optimizar aquellas consultas que generen mucho
trafico de salida, claro siempre que se pueda.

Al momento he optimizado la base datos desde los siguientes puntos de vista:
1. Consultas Lentas
2. Cantidad de registros devueltos por consultas.
3. Consultas repetitivas (uso de cache)

Y ya estoy usando herramientas como pgbadger y pg_stat_statements para
hacer analisis, que mas podria usar para buscar optimizaciones, y en
particular medir el trafico de red?
Gracias por su ayuda.

Re: Consulta sobre Json o jsonb

[Horacio Miranda]

On 11/11/2020 4:27 pm, Silvana Flores wrote:


hola a todos esperando que se encuentren bien, les quiero solicitar 
información, he estado  leyendo sobre los tipos de datos json y 
jasonb, tengo una consulta que no he logrado llegar a aclarar,   estos 
tipos de datos se han creado con el objetivo de  almacenar datos tipo 
BD nosql  o para 'saltar' implementar un  werbservice para consultar 
la bd en aplicaciones web o dispositivos móviles. Si alguien me puede 
recomendar un link para  para orientar  se lo agradeceria...

Saludos y gracias por su constante  ayuda.


Hola, como lo veo los json o los XML son un objeto, no un texto.

los objetos tienen propiedades y funciones, esto es super importante por 
que los desarrolladores se pueden confundir y terminar haciendo 
operaciones de tipo strings en objetos y no usar las funciones.


Me toco ver problemas de performance donde un XML era leido 70 veces 
para armar el XML, linea por linea en vez de usar la funcion.


Lo importante es si usas XML o JSON revisa la documentación como generar 
un JSON desde SQL ( el motor lo puede generar ).


Buscando en google encontre esto.
https://devhints.io/postgresql-json

https://www.enterprisedb.com/edb-docs/d/postgresql/reference/manual/12.1/functions-json.html

( y es super importante cuando decidas probar las API o el web service, 
prueba como se comporta con carga ) jmeter o WRK son buenas herramientas 
para probar.


https://github.com/giltene/wrk2

Re: Consulta - Permitir conexiones entrantes a un servidor PostgreSQL y Servidor Web

[Carlos Perez]

Hola Fernando. con buenas credenciales no vas a tener problemas... no
obstante siempre es recomendable redirigir aunque sea arriba del 10.000
para evitar que sniffeen
saludos.

El vie, 27 nov 2020 a las 16:45, Kospi ()
escribió:

> Buenas tardes!
> tal vez los mas experimentados/conocedores puedan orientarme.
> Es muy inseguro dejar abierto el puerto 5432 de postgres en un servidor
> web?
> La idea era permitir interactuar una aplicacion web con otra aplicacion de
> escritorio.
> O es preferible comunicarse desarrollar un web service?
> Que me recomiendan?
> Saludos y gracias de antemano!
> Fernando
>


-- 
--
Carlos Enrique Perez, +5411-95402-8667
Managing Director
* ___*
*|   |> syswarp *
*|___|  *
www.syswarp.com

Consulta - Permitir conexiones entrantes a un servidor PostgreSQL y Servidor Web

[Kospi]

Buenas tardes!
tal vez los mas experimentados/conocedores puedan orientarme.
Es muy inseguro dejar abierto el puerto 5432 de postgres en un servidor web?
La idea era permitir interactuar una aplicacion web con otra aplicacion de
escritorio.
O es preferible comunicarse desarrollar un web service?
Que me recomiendan?
Saludos y gracias de antemano!
Fernando

Re: consulta hibernate

[Juan José Santamaría Flecha]

On Thu, Nov 19, 2020 at 2:18 PM Hellmuth Vargas  wrote:

>
> Por aqui nuevamente poniendo oficio!, tengo una aplicación que emplea
> Hibernate para su persistencia (se está ejecutando en un PostgreSQL 11.7 )
> dentro de las consultas que se están ejecutando de forma frecuente, esta no
> se ha podido optimizar:
>

Cuando me ha tocado intentar optimizar la ejecución de consultas generadas
por Hibernate como estas, lo que evitaba que los costes se disparasen era
subir el join_collapse_limit. Pero en algún caso eso resultaba en tiempos
de parse altos para consultas que luego eran rápidas en ejecución, y en
esos casos forzar el uso del optimizador genético, bajando los valores
de geqo_threshold y geqo_effort, fue con lo que conseguimos
mejores resultados.

Un saludo,

Juan José Santamaría Flecha

consulta hibernate

[Hellmuth Vargas]

omensaje_comp3 on
audiomensaje  (cost=0.08..820.53 rows=1 width=14205) (actual
time=3.556..3.556 rows=0 loops=39)
  Index Cond: ((fechacreacion >= '2020-11-01
00:00:00'::timestamp without time zone) AND ((queue)::text = ANY
('{colaA,colaB,colaC}'::text[])))
Planning Time: 2.152 ms
Execution Time: 6371.748 ms


---
Reescribir la consulta para evitar que el haga el union sobre todo los
registros  las tablas y luego si filtrar, la consulta quedaría asi:


select carac0_.id as id10_, carac0_.guion_id as guion13_10_,
carac0_.nombreClase as nombreCl3_10_, carac0_.nombreGuion as nombreGu4_10_,
carac0_.observaciones as observac5_10_, carac0_.people as persona14_10_,
carac0_.tipificacion_id as tipific15_10_, carac0_.uniqueid as uniqueid10_,
carac0_.usuarioGestionaId as usuarioG7_10_, carac0_.fechaRemarcacion as
fechaRem8_10_, carac0_.numeroIntento as numeroIn9_10_, carac0_.prioridad as
prioridad10_, carac0_.telefonoActivo as telefon11_10_,
carac0_.telefonoRemarcacion as telefon12_10_, carac0_.DTYPE as DTYPE10_
from public.caracterizacionPantalla carac0_
join public.people peo2_ on carac0_.people=peo2_.id  and
peo2_.identificacion='1234567890'
join lateral (
select id, fechaCreacion, fechaModificacion, idUsuarioCrea,
idUsuarioModifica, agent, agentChannel, apellidoCliente, callerId,
callerIdName, chanel, fechaGrabacion, fechaHoraContacto,
idServidorTelefonia, identificacionCliente, nombreCliente, queue,
tipoIdentificacionCliente, tipoLlamada, uniqueId, documento, fecha,
fechaInicioGestion, casoCrm_id, people_id, usuario_id, departamento,
estadoCivil, fechaAsigna, fechaNac, genero, guionBaseSalida_id,
guionOriginalSalida_id, datocomplementario1, datocomplementario2,
datocomplementario3, datocomplementario4, municipio, primerApellido,
primerNombre, segundoApellido, segundoNombre, telefono1, telefono2,
telefono3, telefono4, tipoDocumento, marcadorLista_id, usuarioAsigna_id,
usuarioAsignado_id, direccion, email, fechaEvento, horaEvento, lugarEvento,
motivo, motivoDescripcion, guionHtml_id, categoriaFormulario, formGuion_id,
categoriaVerificado, formVerificacion_id, null::varchar as audio,
null::int8 as idBase, null::varchar as identificacion, null::varchar as
nombres, null::varchar as autorizaFactura, null::varchar as celularTutor,
null::varchar as ciudadAtencion, null::bool as consultoEstadoCuenta,
null::bool as consultoPlantillaEstado, null::bool as consultoTickets,
null::varchar as descripcion, null::varchar as detalleTransaccion,
null::varchar as errorDetail, null::varchar as estadoBot, null::varchar as
idCalificador, null::varchar as idCredito, null::varchar as
identificacionTutor, null::int4 as intentosCreacionCasoCosmos,
null::varchar as menorEdad, null::varchar as motivoWSCosmos, null::varchar
as motivoWSCosmosNombre, null::varchar as nombreTutor, null::varchar as
numeroTicket, null::varchar as resultWSBPM, null::bool as
resultadoWSCosmos, null::int8 as smsOutboundId, null::varchar as
telefonoTutor, null::varchar as tipoIdentificacionTutor, null::varchar as
wsTipBotResult, null::int8 as canalAtencion_id, null::int8 as
tipEscalamiento_id, null::int8 as tipoBotInputData_id, null::int8 as
tipoCanalWsCosmos_id, null::int8 as tipoCliente_id, null::int8 as
twitterConversacion_idInvitado, null::int8 as twitterTweet_id, null::int8
as tipIndisponibilidad_id, null::int8 as directorio_id, null::bool as
enviarSms, 4 as clazz_
 from public.GuionSimpleVerificado where carac0_.guion_id=id  union all
select id, fechaCreacion, fechaModificacion, idUsuarioCrea,
idUsuarioModifica, agent, agentChannel, apellidoCliente, callerId,
callerIdName, chanel, fechaGrabacion, fechaHoraContacto,
idServidorTelefonia, identificacionCliente, nombreCliente, queue,
tipoIdentificacionCliente, tipoLlamada, uniqueId, documento, fecha,
fechaInicioGestion, casoCrm_id, people_id, usuario_id, departamento,
estadoCivil, fechaAsigna, fechaNac, genero, guionBaseSalida_id,
guionOriginalSalida_id, datocomplementario1, datocomplementario2,
datocomplementario3, datocomplementario4, municipio, primerApellido,
primerNombre, segundoApellido, segundoNombre, telefono1, telefono2,
telefono3, telefono4, tipoDocumento, marcadorLista_id, usuarioAsigna_id,
usuarioAsignado_id, direccion, email, fechaEvento, horaEvento, lugarEvento,
motivo, motivoDescripcion, guionHtml_id, categoriaFormulario, formGuion_id,
null::varchar as categoriaVerificado, null::int8 as formVerificacion_id,
null::varchar as audio, null::int8 as idBase, null::varchar as
identificacion, null::varchar as nombres, autorizaFactura, celularTutor,
ciudadAtencion, consultoEstadoCuenta, consultoPlantillaEstado,
consultoTickets, descripcion, detalleTransaccion, errorDetail, estadoBot,
idCalificador, idCredito, identificacionTutor, intentosCreacionCasoCosmos,
menorEdad, motivoWSCosmos, motivoWSCosmosNombre, nombreTutor, numeroTicket,
resultWSBPM, resultadoWSCosmos, smsOutboundId, telefonoTutor,
tipoIdentificacionTutor, wsTipBotResult, canalAten

Re: Consulta sobre Json o jsonb

[Alvaro Herrera]

Silvana Flores escribió:
> hola a todos esperando que se encuentren bien, les quiero solicitar
> información, he estado  leyendo sobre los tipos de datos json y jasonb,
> tengo una consulta que no he logrado llegar a aclarar,   estos tipos de
> datos se han creado con el objetivo de  almacenar datos tipo BD nosql  o
> para 'saltar' implementar un  werbservice para consultar la bd en
> aplicaciones web o dispositivos móviles. Si alguien me puede recomendar un
> link para  para orientar  se lo agradeceria...

Puedes almacenar en la base de datos los datos JSON que le enviarás a
los dispositivos, aunque se asume que tienes una aplicación que es la
que interactúa con los dispositivos.  Conectar un móvil directamente a
una BD sería una locura, creo yo, aunque creo que no es imposible.

Consulta sobre Json o jsonb

[Silvana Flores]

hola a todos esperando que se encuentren bien, les quiero solicitar
información, he estado  leyendo sobre los tipos de datos json y jasonb,
tengo una consulta que no he logrado llegar a aclarar,   estos tipos de
datos se han creado con el objetivo de  almacenar datos tipo BD nosql  o
para 'saltar' implementar un  werbservice para consultar la bd en
aplicaciones web o dispositivos móviles. Si alguien me puede recomendar un
link para  para orientar  se lo agradeceria...
Saludos y gracias por su constante  ayuda.

Re: Consulta sobre permisos

[Diego]

Hola Fernando,

No, no aplica a nivel db. fijate en la docu 
https://www.postgresql.org/docs/current/sql-grant.html porque también 
cambia según los permisos de quien lo ejecuta.


Salu2

On 2020-11-07 14:29, Romero, Fernando wrote:


Hola como están.

Tengo una duda con los permisos en postgres, vengo del mundo Oracle y 
estoy aprendiendo las diferencias


Si corro un grant all privileges on database a un usuario le estoy 
dando permisos de todo, también para crear tablas no?


Saludos

“El contenido del presente mensaje (y sus anexos) es privado, 
confidencial y de exclusivo uso para el destinatario referenciado; es 
de público conocimiento que las comunicaciones por medio de Internet 
no permiten asegurar ni garantizar la confidencialidad de los mensajes 
transmitidos, así como tampoco su integridad o su correcta recepción; 
es por ello que SOFSE no se responsabiliza de posibles perjuicios 
derivados de la captura, incorporaciones de virus o cualquier otra 
manipulación efectuada por terceros. Las opiniones expresadas en este 
mensaje y en los archivos adjuntos son propias del remitente y no 
representan la opinión o políticas de SOFSE, salvo que se diga 
expresamente y el remitente se encuentre autorizado para ello” 

Consulta sobre permisos

[Romero, Fernando]

Hola como están.
Tengo una duda con los permisos en postgres, vengo del mundo Oracle y estoy 
aprendiendo las diferencias
Si corro un grant all privileges on database a un usuario le estoy dando 
permisos de todo, también para crear tablas no?

Saludos

"El contenido del presente mensaje (y sus anexos) es privado, confidencial y de 
exclusivo uso para el destinatario referenciado; es de público conocimiento que 
las comunicaciones por medio de Internet no permiten asegurar ni garantizar la 
confidencialidad de los mensajes transmitidos, así como tampoco su integridad o 
su correcta recepción; es por ello que SOFSE no se responsabiliza de posibles 
perjuicios derivados de la captura, incorporaciones de virus o cualquier otra 
manipulación efectuada por terceros. Las opiniones expresadas en este mensaje y 
en los archivos adjuntos son propias del remitente y no representan la opinión 
o políticas de SOFSE, salvo que se diga expresamente y el remitente se 
encuentre autorizado para ello"

Re: Consulta lenta

[Alvaro Herrera]

Jairo Graterón escribió:

> explain  select max(id) from invoices where num_ruc='20524953189';
> QUERY PLAN
> 
> ---
>  Result  (cost=474.18..474.19 rows=1 width=8)
>InitPlan 1 (returns $0)
>  ->  Limit  (cost=0.57..474.18 rows=1 width=8)
>->  Index Scan Backward using invoices_pkey on ose_ticket
>  (cost=0.57..8389569.35 rows=17714 width=8)
>  Index Cond: (id IS NOT NULL)
>  Filter: ((num_ruc)::text = '20524953189'::text)
> (6 rows)
> 
> El campo num_ruc está indexado pero el motor decide que usa el índice del
> id y busca con filter el num_ruc

Muestra el \d de la tabla.

Re: Consulta lenta

[Jairo Graterón]

Hola Alvaro,

Las fechas están correctas, la versión postgresql 12 veo que usa mucho las
búsquedas en el heap antes de usar los índices, tal vez un problema de
configuración.

Otro ejemplo es la siguiente consulta que tarda una eternidad, y se supone
que no hay registro que coincida en el where

explain  select max(id) from invoices where num_ruc='20524953189';
QUERY PLAN

---
 Result  (cost=474.18..474.19 rows=1 width=8)
   InitPlan 1 (returns $0)
 ->  Limit  (cost=0.57..474.18 rows=1 width=8)
   ->  Index Scan Backward using invoices_pkey on ose_ticket
 (cost=0.57..8389569.35 rows=17714 width=8)
 Index Cond: (id IS NOT NULL)
 Filter: ((num_ruc)::text = '20524953189'::text)
(6 rows)

El campo num_ruc está indexado pero el motor decide que usa el índice del
id y busca con filter el num_ruc

*Ahora si la consulta uso CTE la respuesta es instantánea*

explain (analyze,buffers) with T1 as (select id from invoices where
num_ruc='20524953189') select max(id) from T1;
   QUERY
PLAN
-
 Aggregate  (cost=67413.58..67413.59 rows=1 width=8) (actual
time=0.019..0.019 rows=1 loops=1)
   Buffers: shared hit=4
   ->  Bitmap Heap Scan on invoices  (cost=701.85..67369.30 rows=17714
width=8) (actual time=0.016..0.017 rows=0 loops=1)
 Recheck Cond: ((num_ruc)::text = '20524953189'::text)
 Buffers: shared hit=4
 ->  Bitmap Index Scan on idx7tfrebfdhytkiavp6fobro3ct
 (cost=0.00..697.42 rows=17714 width=0) (actual time=0.015..0.016 rows=0
loops=1)
   Index Cond: ((num_ruc)::text = '20524953189'::text)
   Buffers: shared hit=4
 Planning Time: 0.076 ms
 Execution Time: 0.039 ms
(10 rows)

Estás cosas no pasaban con la versión anterior "9.6", seguiré probando a
ver si encuentro el problema o migro a la versión 10 o 11.

Saludos.

El mié., 14 oct. 2020 a las 16:19, Alvaro Herrera ()
escribió:

> Jairo Graterón escribió:
>
> > Ahora tenemos una consulta lenta que está afectando el rendimiento en el
> > sistema
>
> y cual era la consulta?
>
> Lo que me parece mas sospechoso es que los literales de la columna
> fecha_de_emision son timestamp without time zone. Quizas estas pasando
> el tipo de dato equivocado en esa columna y por eso no usa ningun
> indice.  Es JDBC esto?  o sentencias preparadas?
>
> Saludos
>
>
>

Re: Consulta lenta

[Jairo Graterón]

Hola Horacio aquí está la consulta

explain (analyze,buffers)
select count(*), count(*) filter (where fecha_de_emision >= '2020-09-01
05:00:00' and fecha_de_emision <  '2020-10-01 05:00:00') from invoices;
QUERY PLAN


 Aggregate  (cost=4404228.16..4404228.17 rows=1 width=16) (actual
time=122785.413..122785.415 rows=1 loops=1)
   Buffers: shared hit=321622 read=2501337 dirtied=279 written=65
   ->  Seq Scan on invoices  (cost=0.00..3613593.58 rows=79063458 width=11)
(actual time=0.757..108997.146 rows=78901597 loops=1)
 Buffers: shared hit=321622 read=2501337 dirtied=279 written=65
 Planning Time: 0.067 ms
 JIT:
   Functions: 3
   Options: Inlining true, Optimization true, Expressions true, Deforming
true
   Timing: Generation 0.404 ms, Inlining 34.157 ms, Optimization 31.163 ms,
Emission 20.213 ms, Total 85.937 ms
 Execution Time: 122785.916 ms
(10 rows)




El mié., 14 oct. 2020 a las 4:16, Horacio Miranda ()
escribió:

>
> On 8/10/2020 10:18 am, Jairo Graterón wrote:
>
> Sí gracias. Se pudo resolver ese tema en particular y se usó el tipo de
> índice predeterminado que usa postgres.
>
> Aquí está el resultado de la consulta que solicitaste.
>
> => explain select count(*), count(*) filter (where fecha_de_emision >=
> '2020-09-01 05:00:00' and fecha_de_emision <  '2020-10-01 05:00:00') from
> invoices;
>QUERY PLAN
>
>
> 
>  Aggregate  (cost=3431745.91..3431745.92 rows=1 width=16)
>->  Index Only Scan using idxpdo46192ooj1ys1xxkcknhsy0 on invoices
>  (cost=0.57..2660899.27 rows=77084664 width=11)
>  JIT:
>Functions: 2
>Options: Inlining true, Optimization true, Expressions true, Deforming
> true
> (5 rows)
>
> => select count(*), count(*) filter (where fecha_de_emision >= '2020-09-01
> 05:00:00' and fecha_de_emision <  '2020-10-01 05:00:00') from invoices;
>   count   |  count
> --+-
>  77322360 | 3679203
> (1 row)
> Time: 15702.502 ms (00:15.703)
>
> Es posible hacer esto.
>
> explain (analyze,buffers)
> select count(*), count(*) filter (where fecha_de_emision >= '2020-09-01
> 05:00:00' and fecha_de_emision <  '2020-10-01 05:00:00') from invoices;
>
>
>
> Estamos analizando las diferencias del tiempo de ejecución de algunas
> consultas ya que no tienen la misma respuesta al cambiar de postgres 9.6 a
> 12
>
> Sospecho que no es el mismo hardware, a pesar que tiene igual
> configuración de 32 GB de RAM, disco SSD de 500GB en una instancia AWS de 8
> cores.
>
> Llega un momento que al presentarse más de 3mil request por minuto las
> consultas demoran mucho para finalizar y se degrada el rendimiento en
> general.
>
> No hay cambios en el frontend, sólo se migró a la nueva versión del gestor
> y se perdió la sensación de rapidez que tenía la versión anterior,
>
> El sistema ahora está un poco más estable al crear y/o eliminar índices
> que mejoró notablemente.
>
> Seguiré revisando el porqué se degradó el performance.
>
> Saludos
>
> El mié., 7 oct. 2020 a las 2:46, Jaime Casanova (<
> jaime.casan...@2ndquadrant.com>) escribió:
>
>> On Mon, 28 Sep 2020 at 16:16, Jairo Graterón  wrote:
>>
>>> Saludos lista, recientemente migramos de postgresql 9.6 a 12
>>>
>>> Ahora tenemos una consulta lenta que está afectando el rendimiento en el
>>> sistema
>>>
>>> Observo que en el explain el motor no está usando el índice del
>>> campo fecha_de_emision
>>>
>>>
>> Saludos,
>>
>> ¿Pudiste solucionar el problema? porque te pidieron el explain analyze
>> pero no veo que hayas pasado.
>>
>>  puedes mostrar el resultado de:
>>
>> select count(*),
>>count(*) filter (where fecha_de_emision >= '2020-09-01
>> 05:00:00' and fecha_de_emision <=  '2020-10-01 04:59:59.99'
>>from invoices;
>>
>>
>> además de la estructura de invoices obtenida con \d en psql (por favor,
>> no uses imagenes, pon esas cosas que te pedí en archivos de texto y
>> adjuntalos. gracias)
>>
>> --
>> Jaime Casanova  www.2ndQuadrant.com
>> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>>
>

Re: Consulta lenta

[Alvaro Herrera]

Jairo Graterón escribió:

> Ahora tenemos una consulta lenta que está afectando el rendimiento en el
> sistema

y cual era la consulta?

Lo que me parece mas sospechoso es que los literales de la columna
fecha_de_emision son timestamp without time zone. Quizas estas pasando
el tipo de dato equivocado en esa columna y por eso no usa ningun
indice.  Es JDBC esto?  o sentencias preparadas?

Saludos

Re: Consulta lenta

[Horacio Miranda]

On 8/10/2020 10:18 am, Jairo Graterón wrote:
Sí gracias. Se pudo resolver ese tema en particular y se usó el tipo 
de índice predeterminado que usa postgres.


Aquí está el resultado de la consulta que solicitaste.

=> explain select count(*), count(*) filter (where fecha_de_emision >= 
'2020-09-01 05:00:00' and fecha_de_emision <  '2020-10-01 05:00:00') 
from invoices;

                                                       QUERY PLAN

 Aggregate  (cost=3431745.91..3431745.92 rows=1 width=16)
   ->  Index Only Scan using idxpdo46192ooj1ys1xxkcknhsy0 on invoices 
 (cost=0.57..2660899.27 rows=77084664 width=11)

 JIT:
   Functions: 2
   Options: Inlining true, Optimization true, Expressions true, 
Deforming true

(5 rows)

=> select count(*), count(*) filter (where fecha_de_emision >= 
'2020-09-01 05:00:00' and fecha_de_emision <  '2020-10-01 05:00:00') 
from invoices;

  count   |  count
--+-
 77322360 | 3679203
(1 row)
Time: 15702.502 ms (00:15.703)


Es posible hacer esto.

explain (analyze,buffers)
select count(*), count(*) filter (where fecha_de_emision >= '2020-09-01 
05:00:00' and fecha_de_emision <  '2020-10-01 05:00:00') from invoices;





Estamos analizando las diferencias del tiempo de ejecución de algunas 
consultas ya que no tienen la misma respuesta al cambiar de postgres 
9.6 a 12


Sospecho que no es el mismo hardware, a pesar que tiene igual 
configuración de 32 GB de RAM, disco SSD de 500GB en una instancia AWS 
de 8 cores.


Llega un momento que al presentarse más de 3mil request por minuto las 
consultas demoran mucho para finalizar y se degrada el rendimiento en 
general.


No hay cambios en el frontend, sólo se migró a la nueva versión del 
gestor y se perdió la sensación de rapidez que tenía la versión anterior,


El sistema ahora está un poco más estable al crear y/o eliminar 
índices que mejoró notablemente.


Seguiré revisando el porqué se degradó el performance.

Saludos

El mié., 7 oct. 2020 a las 2:46, Jaime Casanova 
(<mailto:jaime.casan...@2ndquadrant.com>>) escribió:


On Mon, 28 Sep 2020 at 16:16, Jairo Graterón mailto:jgrate...@gmail.com>> wrote:

Saludos lista, recientemente migramos de postgresql 9.6 a 12

Ahora tenemos una consulta lenta que está afectando el
rendimiento en el sistema

Observo que en el explain el motor no está usando el índice
del campo fecha_de_emision


Saludos,

¿Pudiste solucionar el problema? porque te pidieron el explain
analyze pero no veo que hayas pasado.

 puedes mostrar el resultado de:

select count(*),
           count(*) filter (where fecha_de_emision >= '2020-09-01
05:00:00' and fecha_de_emision <=  '2020-10-01 04:59:59.99'
   from invoices;


además de la estructura de invoices obtenida con \d en psql (por
favor, no uses imagenes, pon esas cosas que te pedí en archivos de
texto y adjuntalos. gracias)

-- 
Jaime Casanova www.2ndQuadrant.com <http://www.2ndQuadrant.com>

PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: Consulta lenta

[Jairo Graterón]

Sí gracias. Se pudo resolver ese tema en particular y se usó el tipo de
índice predeterminado que usa postgres.

Aquí está el resultado de la consulta que solicitaste.

=> explain select count(*), count(*) filter (where fecha_de_emision >=
'2020-09-01 05:00:00' and fecha_de_emision <  '2020-10-01 05:00:00') from
invoices;
   QUERY PLAN


 Aggregate  (cost=3431745.91..3431745.92 rows=1 width=16)
   ->  Index Only Scan using idxpdo46192ooj1ys1xxkcknhsy0 on invoices
 (cost=0.57..2660899.27 rows=77084664 width=11)
 JIT:
   Functions: 2
   Options: Inlining true, Optimization true, Expressions true, Deforming
true
(5 rows)

=> select count(*), count(*) filter (where fecha_de_emision >= '2020-09-01
05:00:00' and fecha_de_emision <  '2020-10-01 05:00:00') from invoices;
  count   |  count
--+-
 77322360 | 3679203
(1 row)
Time: 15702.502 ms (00:15.703)


Estamos analizando las diferencias del tiempo de ejecución de algunas
consultas ya que no tienen la misma respuesta al cambiar de postgres 9.6 a
12

Sospecho que no es el mismo hardware, a pesar que tiene igual configuración
de 32 GB de RAM, disco SSD de 500GB en una instancia AWS de 8 cores.

Llega un momento que al presentarse más de 3mil request por minuto las
consultas demoran mucho para finalizar y se degrada el rendimiento en
general.

No hay cambios en el frontend, sólo se migró a la nueva versión del gestor
y se perdió la sensación de rapidez que tenía la versión anterior,

El sistema ahora está un poco más estable al crear y/o eliminar índices que
mejoró notablemente.

Seguiré revisando el porqué se degradó el performance.

Saludos

El mié., 7 oct. 2020 a las 2:46, Jaime Casanova (<
jaime.casan...@2ndquadrant.com>) escribió:

> On Mon, 28 Sep 2020 at 16:16, Jairo Graterón  wrote:
>
>> Saludos lista, recientemente migramos de postgresql 9.6 a 12
>>
>> Ahora tenemos una consulta lenta que está afectando el rendimiento en el
>> sistema
>>
>> Observo que en el explain el motor no está usando el índice del
>> campo fecha_de_emision
>>
>>
> Saludos,
>
> ¿Pudiste solucionar el problema? porque te pidieron el explain analyze
> pero no veo que hayas pasado.
>
>  puedes mostrar el resultado de:
>
> select count(*),
>count(*) filter (where fecha_de_emision >= '2020-09-01
> 05:00:00' and fecha_de_emision <=  '2020-10-01 04:59:59.99'
>from invoices;
>
>
> además de la estructura de invoices obtenida con \d en psql (por favor, no
> uses imagenes, pon esas cosas que te pedí en archivos de texto y
> adjuntalos. gracias)
>
> --
> Jaime Casanova  www.2ndQuadrant.com
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>

Re: Consulta lenta

[Francisco Olarte]

Jaime, un comentario:

On Wed, Oct 7, 2020 at 8:46 AM Jaime Casanova
 wrote:
..
>  puedes mostrar el resultado de:
> select count(*),
>count(*) filter (where fecha_de_emision >= '2020-09-01 05:00:00' 
> and fecha_de_emision <=  '2020-10-01 04:59:59.99'
>from invoices;

Salvo que tengas muy buenas razones para no hacerla, que yo no las he
tenido en 30 años, es mejor manejar todas las cosas que sean
asimilables a numeros reales, puntos en una recta, con intervalos
semiabiertos:

select count(*),
   count(*) filter (where fecha_de_emision >= '2020-09-01
05:00:00' and fecha_de_emision <  '2020-10-01 05:00:00'

Son mas faciles de escribir, cubren la recta sin solaparse y te evitas
tener que pensar en que precision tienen los campos ( i.e., que pasa
si el postgres 27.8 empieza a manejar los timestamps con precision de
picosegundos, porque todas las CPUs usadas en los ultimos 10 años son
de 128 bits y es mas comodo/preciso ).

FOS.

Re: Consulta lenta

[Jaime Casanova]

On Mon, 28 Sep 2020 at 16:16, Jairo Graterón  wrote:

> Saludos lista, recientemente migramos de postgresql 9.6 a 12
>
> Ahora tenemos una consulta lenta que está afectando el rendimiento en el
> sistema
>
> Observo que en el explain el motor no está usando el índice del
> campo fecha_de_emision
>
>
Saludos,

¿Pudiste solucionar el problema? porque te pidieron el explain analyze pero
no veo que hayas pasado.

 puedes mostrar el resultado de:

select count(*),
   count(*) filter (where fecha_de_emision >= '2020-09-01 05:00:00'
and fecha_de_emision <=  '2020-10-01 04:59:59.99'
   from invoices;


además de la estructura de invoices obtenida con \d en psql (por favor, no
uses imagenes, pon esas cosas que te pedí en archivos de texto y
adjuntalos. gracias)

-- 
Jaime Casanova  www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services