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
> 
> owasp.org 
> [image: favicon.ico]
> 
> 
>
> 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
> 
>  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 
> 
>  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
> 

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

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

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

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

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.

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

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

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)

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

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

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.

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

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

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.

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” 

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 
(>) 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 

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

Re: Consulta de ddl trigger

[Diego]

Mil gracias a todos,

Finalmente, termine usando current_query(), que si bien puede retornar 
varias consultas, fue mas fácil de manipular (para mis conocimientos).


Diego,

On 2020-09-24 22:43, Alvaro Herrera wrote:

Stephen Amell escribió:

Buenas tardes lista!

¿saben si puedo capturar el comando exacto de ddl que me están ejecutando,
tipo un alter table?

Sí se puede, pero necesitas código en C.  Hay un módulo simplista en el
código de postgres, src/test/modules/test_ddl_deparse, que muestra cómo
hacerlo.  El módulo en sí no es útil, pero te da pistas de cómo empezar
a escribir algo más completo.

Si tienes necesidad muy fuerte de muchos detalles, hay código en otra
parte que te puede entregar el DDL completo en un formato JSON dedicado.
No es necesario que lo adoptes completo pero podrías tomar prestada la
parte que te haga falta.


Xq en la docu dice que no se puede usar el dato del campo command
directamente.

Es cierto.

Re: RE: Consulta hit ratio

[Alvaro Herrera]

Romero, Fernando escribió:
>Romero, Fernando
>fernando.rom...@trenesargentinos.gob.ar

¡Este mail es otro virus!   ¡No abra el .doc!

-- 
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

RE: Consulta hit ratio

[Romero, Fernando]

-Mensaje original-
De: Alvaro Herrera [mailto:alvhe...@2ndquadrant.com]
Enviado el: jueves, 24 de septiembre de 2020 22:48
Para: Romero, Fernando 
CC: Martín Marqués ; Ayuda 

Asunto: Re: Consulta hit ratio

Romero, Fernando escribió:

> El servidor tiene 32GB solo para postgres, hay alguna otra forma de 
> aprovechar eso y darle mas recursos a la base?

¿De qué tamaño es la BD?  Es posible que puedas subir shared_buffers y que te 
dé buenos resultados.  Prueba con 8, 12, 16 GB a ver qué pasa.

--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

La base pesa 30GB

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 hit ratio

[Alvaro Herrera]

Romero, Fernando escribió:

> El servidor tiene 32GB solo para postgres, hay alguna otra forma de 
> aprovechar eso y darle mas recursos a la base?

¿De qué tamaño es la BD?  Es posible que puedas subir shared_buffers
y que te dé buenos resultados.  Prueba con 8, 12, 16 GB a ver qué pasa.

-- 
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: Consulta de ddl trigger

[Alvaro Herrera]

Stephen Amell escribió:
> Buenas tardes lista!
> 
> ¿saben si puedo capturar el comando exacto de ddl que me están ejecutando,
> tipo un alter table?

Sí se puede, pero necesitas código en C.  Hay un módulo simplista en el
código de postgres, src/test/modules/test_ddl_deparse, que muestra cómo
hacerlo.  El módulo en sí no es útil, pero te da pistas de cómo empezar
a escribir algo más completo.

Si tienes necesidad muy fuerte de muchos detalles, hay código en otra
parte que te puede entregar el DDL completo en un formato JSON dedicado.
No es necesario que lo adoptes completo pero podrías tomar prestada la
parte que te haga falta.

> Xq en la docu dice que no se puede usar el dato del campo command
> directamente.

Es cierto.

-- 
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

RE: Consulta hit ratio

[Romero, Fernando]

De: Martín Marqués [mailto:martin.marq...@gmail.com]
Enviado el: lunes, 21 de septiembre de 2020 17:39
Para: Romero, Fernando 
CC: Ayuda 
Asunto: Re: Consulta hit ratio

Buenas,

El vie., 18 sept. 2020 a las 18:09, Romero, Fernando 
(mailto:fernando.rom...@trenesargentinos.gob.ar>>)
 escribió:
Hola como están, tengo una duda con el hit ratio de la base, el ratio es del 
97% el servidor donde corre (un RDS en aws) tiene 32GB para la base.
El shared buffer en el postgresql.conf tiene asignado un poco mas de 1GB, si 
subo lo asignado para el shared buffer mejoraría el % de aciertos?.

Con ese porcentaje de hit ratio, yo no tocaria shared_buffers.

Saludos,

--
Martín Marqués
It’s not that I have something to hide,
it’s that I have nothing I want you to see


Hola Martin gracias por tu respuesta.
El servidor tiene 32GB solo para postgres, hay alguna otra forma de aprovechar 
eso y darle mas recursos a la base?

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 hit ratio

[Martín Marqués]

Buenas,

El vie., 18 sept. 2020 a las 18:09, Romero, Fernando (<
fernando.rom...@trenesargentinos.gob.ar>) escribió:

> Hola como están, tengo una duda con el hit ratio de la base, el ratio es
> del 97% el servidor donde corre (un RDS en aws) tiene 32GB para la base.
>
> El shared buffer en el postgresql.conf tiene asignado un poco mas de 1GB,
> si subo lo asignado para el shared buffer mejoraría el % de aciertos?.
>

Con ese porcentaje de hit ratio, yo no tocaria shared_buffers.

Saludos,

-- 
Martín Marqués
It’s not that I have something to hide,
it’s that I have nothing I want you to see

Re: Consulta sobre monitoreo de índices

[Francisco Olarte]

On Mon, Sep 14, 2020 at 6:13 PM Romero, Fernando
 wrote:
> Estoy viendo monitoreo de índices la versión que estoy usando de postgres es 
> la 10, para ver los índices que no se están usando consulto la vista 
> pg_stat_user_indexes y le hago un join con la pg_index, el query que uso es 
> este

> Le hice un explain a una tabla que tenia un índice que con el query me tirba 
> como que no se usaba y en el explain veo que si entra por ese índice.

Pone "Index scan" en el explain? ( a ver si es un acceso a una fila
unica y eso te lo cuenta en los tup_* pero no el _scans ) .

Francisco Olarte.

Re: Consulta sobre monitoreo de índices

[Juan José Santamaría Flecha]

On Mon, Sep 14, 2020 at 6:13 PM Romero, Fernando <
fernando.rom...@trenesargentinos.gob.ar> wrote:

>  *De:* Juan José Santamaría Flecha [mailto:juanjo.santama...@gmail.com]
>
> *Enviado el:* lunes, 14 de septiembre de 2020 12:54
> *Para:* Romero, Fernando ; Ayuda
> 
> *Asunto:* Re: Consulta sobre monitoreo de índices
>
>
>
> Perdón, le había dado a responder sin estar la lista. Por favor, sigue
> este hilo.
>

Gracias.

>
>
> On Mon, Sep 14, 2020 at 5:51 PM Juan José Santamaría Flecha <
> juanjo.santama...@gmail.com> wrote:
>
>
>
> On Mon, Sep 14, 2020 at 4:12 PM Romero, Fernando <
> fernando.rom...@trenesargentinos.gob.ar> wrote:
>
> Hola como están.
>
> Estoy viendo monitoreo de índices la versión que estoy usando de postgres
> es la 10, para ver los índices que no se están usando consulto la vista
> pg_stat_user_indexes y le hago un join con la pg_index, el query que uso es
> este
>
> select
> indexrelid::regclass as index, relid::regclass as table
> from
> pg_stat_user_indexes
> JOIN pg_index USING (indexrelid)
> where
> idx_scan = 0 and indisunique is false;
>
> Lo raro es que me trae casi todo los índices que hay y la mayoría que me
> dice que no se están usando comprobé que si se están usando.
> Hay alguna forma de activar el monitoreo de índices? que no sea con un
> explain tabla por tabla?
>
>
>
> El parámetro que controla esta estadística es "track_counts", que debería
> estar activado por defecto.
>
>
>
> ¿Cómo has comprobado que se están utilizando?
>
> Hola Juan Jose gracias por tu respuesta.
>
> Le hice un explain a una tabla que tenia un índice que con el query me
> tirba como que no se usaba y en el explain veo que si entra por ese índice.
>
> El parámetro track_counts lo tengo en “on”
>

Entonces las que deberían tener razón son las vistas pg_stat_*. Hay casos
en los que el plan explicado manualmente no es el plan ejecutado, ¿la
aplicación utiliza "prepared statements" [1]?

[1] https://www.postgresql.org/docs/10/sql-prepare.html

Un saludo,

Juan José Santamaría Flecha

RE: Consulta sobre monitoreo de índices

[Romero, Fernando]

De: Juan José Santamaría Flecha [mailto:juanjo.santama...@gmail.com]
Enviado el: lunes, 14 de septiembre de 2020 12:54
Para: Romero, Fernando ; Ayuda 

Asunto: Re: Consulta sobre monitoreo de índices

Perdón, le había dado a responder sin estar la lista. Por favor, sigue este 
hilo.

On Mon, Sep 14, 2020 at 5:51 PM Juan José Santamaría Flecha 
mailto:juanjo.santama...@gmail.com>> wrote:

On Mon, Sep 14, 2020 at 4:12 PM Romero, Fernando 
mailto:fernando.rom...@trenesargentinos.gob.ar>>
 wrote:
Hola como están.
Estoy viendo monitoreo de índices la versión que estoy usando de postgres es la 
10, para ver los índices que no se están usando consulto la vista 
pg_stat_user_indexes y le hago un join con la pg_index, el query que uso es este
select
indexrelid::regclass as index, relid::regclass as table
from
pg_stat_user_indexes
JOIN pg_index USING (indexrelid)
where
idx_scan = 0 and indisunique is false;
Lo raro es que me trae casi todo los índices que hay y la mayoría que me dice 
que no se están usando comprobé que si se están usando.
Hay alguna forma de activar el monitoreo de índices? que no sea con un explain 
tabla por tabla?

El parámetro que controla esta estadística es "track_counts", que debería estar 
activado por defecto.

¿Cómo has comprobado que se están utilizando?

Un saludo,

Juan José Santamaría Flecha

Hola Juan Jose gracias por tu respuesta.
Le hice un explain a una tabla que tenia un índice que con el query me tirba 
como que no se usaba y en el explain veo que si entra por ese índice.
El parámetro track_counts lo tengo en “on”

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 sobre monitoreo de índices

[Juan José Santamaría Flecha]

Perdón, le había dado a responder sin estar la lista. Por favor, sigue este
hilo.

On Mon, Sep 14, 2020 at 5:51 PM Juan José Santamaría Flecha <
juanjo.santama...@gmail.com> wrote:

>
> On Mon, Sep 14, 2020 at 4:12 PM Romero, Fernando <
> fernando.rom...@trenesargentinos.gob.ar> wrote:
>
>> Hola como están.
>>
>> Estoy viendo monitoreo de índices la versión que estoy usando de postgres
>> es la 10, para ver los índices que no se están usando consulto la vista
>> pg_stat_user_indexes y le hago un join con la pg_index, el query que uso es
>> este
>>
>> select
>> indexrelid::regclass as index, relid::regclass as table
>> from
>> pg_stat_user_indexes
>> JOIN pg_index USING (indexrelid)
>> where
>> idx_scan = 0 and indisunique is false;
>>
>> Lo raro es que me trae casi todo los índices que hay y la mayoría que me
>> dice que no se están usando comprobé que si se están usando.
>> Hay alguna forma de activar el monitoreo de índices? que no sea con un
>> explain tabla por tabla?
>>
>
> El parámetro que controla esta estadística es "track_counts", que debería
> estar activado por defecto.
>
> ¿Cómo has comprobado que se están utilizando?
>

Un saludo,

Juan José Santamaría Flecha

Re: Consulta sobre collate postgresql

[marcelo mendoza]

Creo que se creó de esa manera, mi consulta es cuál podría ser la
consecuencia y porqué no dió error al momento de crear así la base, vi que
hay comandos para cambiarlo con un update y quisiera saber las implicancias.

Saludos.



El mar., 18 ago. 2020 a las 13:01, Diego ()
escribió:

> Hola Marcelo, me suena a mal editada la pg_database a mano...
> On 2020-08-18 10:03, marcelo mendoza wrote:
>
>
> Buenos días tengo una consulta que les quisiera hacer, tengo el siguiente
> listado de bases de datos, pero en el record 3 se puede ver que el COLLATE
> tiene un espacio en_US.UTF-
>
>   | 8
>
> Esto en que podría afectar a la base de datos?
>
> Desde ya muchas gracias por su ayuda
>
> List of databases
>
> -[ RECORD 1 ]-+--
>
> Name  | xx
>
> Owner | xxx
>
> Encoding  | UTF8
>
> Collate   | en_US.UTF-8
>
> Ctype | en_US.UTF-8
>
> Access privileges |
>
> -[ RECORD 2 ]-+--
>
> Name  | xx
>
> Owner | xxx
>
> Encoding  | UTF8
>
> Collate   | en_US.UTF-8
>
> Ctype | en_US.UTF-8
>
> Access privileges |
>
> -[ RECORD 3 ]-+--
>
> Name  | 
>
> Owner | xxx
>
> Encoding  | UTF8
>
> Collate   | en_US.UTF-
>
>   | 8
>
> Ctype | en_US.UTF-8
>
> Access privileges |
>
>
>
>
>
>
>
>
>
>
>
>

--

Re: Consulta sobre collate postgresql

[marcelo mendoza]

Buenas, si la verdad que se creó así la base, mi consulta sería en qué
afecta y porqué ni dió error al momento de crear la base, a menos de que si
no encuentra ese collate el motor le ponga uno por defecto.

Saludos.


El mar., 18 ago. 2020 a las 13:01, Diego ()
escribió:

> Hola Marcelo, me suena a mal editada la pg_database a mano...
> On 2020-08-18 10:03, marcelo mendoza wrote:
>
>
> Buenos días tengo una consulta que les quisiera hacer, tengo el siguiente
> listado de bases de datos, pero en el record 3 se puede ver que el COLLATE
> tiene un espacio en_US.UTF-
>
>   | 8
>
> Esto en que podría afectar a la base de datos?
>
> Desde ya muchas gracias por su ayuda
>
> List of databases
>
> -[ RECORD 1 ]-+--
>
> Name  | xx
>
> Owner | xxx
>
> Encoding  | UTF8
>
> Collate   | en_US.UTF-8
>
> Ctype | en_US.UTF-8
>
> Access privileges |
>
> -[ RECORD 2 ]-+--
>
> Name  | xx
>
> Owner | xxx
>
> Encoding  | UTF8
>
> Collate   | en_US.UTF-8
>
> Ctype | en_US.UTF-8
>
> Access privileges |
>
> -[ RECORD 3 ]-+--
>
> Name  | 
>
> Owner | xxx
>
> Encoding  | UTF8
>
> Collate   | en_US.UTF-
>
>   | 8
>
> Ctype | en_US.UTF-8
>
> Access privileges |
>
>
>
>
>
>
>
>
>
>
>
>

-- 
Marcelo Mendoza
(0983) 383-752

Re: Consulta sobre collate postgresql

[Diego]

Hola Marcelo, me suena a mal editada la pg_database a mano...

On 2020-08-18 10:03, marcelo mendoza wrote:


Buenos días tengo una consulta que les quisiera hacer, tengo el 
siguiente listado de bases de datos, pero en el record 3 se puede ver 
que el COLLATE tiene un espacio en_US.UTF-


| 8


Esto en que podría afectar a la base de datos?

Desde ya muchas gracias por su ayuda

List of databases

-[ RECORD 1 ]-+--

Name| xx

Owner | xxx

Encoding| UTF8

Collate | en_US.UTF-8

Ctype | en_US.UTF-8

Access privileges |

-[ RECORD 2 ]-+--

Name| xx

Owner | xxx

Encoding| UTF8

Collate | en_US.UTF-8

Ctype | en_US.UTF-8

Access privileges |

-[ RECORD 3 ]-+--

Name| 

Owner | xxx

Encoding| UTF8

Collate | en_US.UTF-

| 8

Ctype | en_US.UTF-8

Access privileges |

Re: Consulta sobre WAL

[Alvaro Herrera]

Pablo Rodriguez escribió:

> Quería consultar lo siguiente, tengo un postres version 10.1 en cluster con
> un pgpool y tengo mi filesystem casi lleno por la
> carpeta /var/lib/postgresql/10/main/archivedir  que por lo que entiendo
> corresponde a los archivos WAL.

Son archivos WAL, pero no es la ubicación crítica para postgres (que es
pg_wal y se "limpia solo").  El archivedir debería ser limpiado con
pg_archivecleanup, según la configuración de tus réplicas y/o respaldos.
Si tu archive_command está guardando los WAL ahí, alguna razón tendrás,
pero en principio parece mala idea.

-- 
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

RE: Consulta valor hora

[Romero, Fernando]

Muchas gracias Horacio.

Saludos

De: Horacio Miranda [mailto:hmira...@gmail.com]
Enviado el: jueves, 6 de agosto de 2020 07:21 a. m.
Para: Romero, Fernando; Ayuda
Asunto: Re: Consulta valor hora


No lo se, en NZ esta cerca de 200 NZD para temas costos, para largo plazo 120 
NZD. (sobre 3 meses de contratos ).
On 6/08/2020 5:24 am, Romero, Fernando wrote:
Hola gente como estan.
Consulta para los que están en Argentina, cuando esta el valor hora de un dba 
postgresql?

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 valor hora

[Horacio Miranda]

No lo se, en NZ esta cerca de 200 NZD para temas costos, para largo 
plazo 120 NZD. (sobre 3 meses de contratos ).


On 6/08/2020 5:24 am, Romero, Fernando wrote:


Hola gente como estan.

Consulta para los que están en Argentina, cuando esta el valor hora de 
un dba postgresql?


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 sobre bases de datos orientadas a microservicios

[Horacio Miranda]

Las bases de datos no son micro-servicios, son centralizadas.

Ahora si quieres tener alta disponibilidad Postgresql soporta HA 
colocando un balanceador de carga con un master y esclavo,


Puedes tener un master, master si quieres sin embargo en lo personal el 
único master-master que me gusta es Oracle RAC, pero es un tema de gusto 
personal.


Lo importante es entender que los micro-servicios son servicios 
orientados,  romper grupos de trabajo, imagina tienes un grupo de 
desarrolladores de facturación y otro de warehouse, entonces separas las 
aplicaciones para tener dos grupos de microservicios, esto lo digo solo 
en caso que esten confundidos con el hecho de separar cosas. mucho.


On 25/06/2020 8:35 am, marcelo mendoza wrote:

Buenas tardes, quisiera consultar cómo están trabajando con sus bases
Postgres con aplicaciones orientadas a microservicios, las bases de 
datos están en contenedores? Tienen un una máquina virtual y dentro un 
servicio de Postgres por cada base? Ya que si el Postgres está 
centralizado y tengo todas las bases de datos en un solo servidor y 
hay que hacer algún reinicio esto afectaría a todos los sistemas.


Desde ya muchas gracias.

Re: Consulta sobre bases de datos orientadas a microservicios

[Miguel Angel Hernandez Moreno]

Hola Marcelo

Por recomendación y en teoría es mucho mejor trabajar con máquinas físicas,
En los microservicios manejo: 1 postgres con todas las bases de datos de
cada ms , que rompe con esa teoría de aislamiento.

Y el reinicio afectaría tu ambiente, depende la tolerancia a los fallos en
la conexión de la bd que tengas, pero si reinicias claro que cierra
conexiones

Espero haber sido de ayuda, excelente fin
Saludos

El mié., 24 jun. 2020 a las 15:35, marcelo mendoza (<
jmarcelo.mend...@gmail.com>) escribió:

> Buenas tardes, quisiera consultar cómo están trabajando con sus bases
> Postgres con aplicaciones orientadas a microservicios, las bases de datos
> están en contenedores? Tienen un una máquina virtual y dentro un servicio
> de Postgres por cada base? Ya que si el Postgres está centralizado y tengo
> todas las bases de datos en un solo servidor y hay que hacer algún reinicio
> esto afectaría a todos los sistemas.
>
> Desde ya muchas gracias.
>


-- 
ISC Miguel Angel Hernandez Moreno

RE: Consulta sobre DISCARD

[Romero, Fernando]

-Mensaje original-
De: Alvaro Herrera [mailto:alvhe...@2ndquadrant.com]
Enviado el: lunes, 13 de enero de 2020 05:12 p. m.
Para: Romero, Fernando
CC: FORO POSTGRES
Asunto: Re: Consulta sobre DISCARD

Romero, Fernando escribió:
> Hola como están, alguien tienen experiencia con DISCARD?
> Estoy teniendo problemas de perfomance cuando se ejecuta DISCARD me mata la 
> base, me usa el 100% de la CPU.

¿qué versión de Postgres?  ¿esto puedes reproducirlo con psql?  Si es así, ¿qué 
pasa si le das un Ctrl-C a psql mientras está ejecutando el DISCARD?

Creo que lo mejor para investigar qué está pasando es tomar un "backtrace" con 
GDB del proceso servidor que está ejecutando DISCARD.
Si pudieras instalar "gcore" y mandar la salida de ejecutarlo en el proceso que 
usa ese 100% de CPU, puede que encontremos algo.

Saludos

--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Hola Alvaro buen dia
La versión de postgres es la 9.4, lo que hice fue habilitar los logs y veo que 
las querys que al ejecutar deja la base muy lentas son las que aparecen como 
DISCARD.

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 sobre DISCARD

[Alvaro Herrera]

Romero, Fernando escribió:
> Hola como están, alguien tienen experiencia con DISCARD?
> Estoy teniendo problemas de perfomance cuando se ejecuta DISCARD me mata la 
> base, me usa el 100% de la CPU.

¿qué versión de Postgres?  ¿esto puedes reproducirlo con psql?  Si es
así, ¿qué pasa si le das un Ctrl-C a psql mientras está ejecutando el
DISCARD?

Creo que lo mejor para investigar qué está pasando es tomar un
"backtrace" con GDB del proceso servidor que está ejecutando DISCARD.
Si pudieras instalar "gcore" y mandar la salida de ejecutarlo en el
proceso que usa ese 100% de CPU, puede que encontremos algo.

Saludos

-- 
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

RE: Consulta sobre DISCARD

[Romero, Fernando]

Esa parte no la entendia, gracias
Cuando se ejecuta el discard la base se pone muy lenta, cualquier consulta 
tarda muchisimo

De: Horacio Miranda [mailto:hmira...@gmail.com]
Enviado el: lunes, 13 de enero de 2020 01:06 a. m.
Para: Romero, Fernando; Enrique Kurth Schoenfeld Escobar; pgsql-es-ayuda
Asunto: Re: Consulta sobre DISCARD



On 13/01/2020 2:32 pm, Romero, Fernando wrote:
Es un vps con 4 CPU y 8GB de memoria si swap
estas usando un 121 % de uan capacidad de 400%, es decir estas usando un 30.25% 
de tu capacidad no estas usando el 100% de la CPU.


De: Enrique Kurth Schoenfeld Escobar [mailto:eku...@live.com.mx]
Enviado el: domingo, 12 de enero de 2020 07:45 p. m.
Para: Horacio Miranda; Romero, Fernando; pgsql-es-ayuda
Asunto: Re: Consulta sobre DISCARD

Hola..
Es virtual o física la maquina?.

Cuantas CPU tiene tu sistema ?

On 13/01/2020 10:30 am, Romero, Fernando wrote:
Ahí esta la primer línea no la había visto

De: Romero, Fernando [mailto:fernando.rom...@trenesargentinos.gob.ar]
Enviado el: domingo, 12 de enero de 2020 06:29 p. m.
Para: Horacio Miranda; FORO POSTGRES
Asunto: RE: Consulta sobre DISCARD

Estas son las únicas líneas que salen, será otro comando?

root@vm-1808948:~# w
18:28:01 up  7:12,  2 users,  load average: 1.21, 1.31, 1.33
USER TTY  FROM LOGIN@   IDLE   JCPU   PCPU WHAT
root pts/0xx   11:172:32m  8.55s  8.50s top
root pts/1xx  18:281.00s  0.02s  0.00s w
root@vm-1808948:~#

De: Horacio Miranda [mailto:hmira...@gmail.com]
Enviado el: domingo, 12 de enero de 2020 06:19 p. m.
Para: Romero, Fernando; FORO POSTGRES
Asunto: Re: Consulta sobre DISCARD

La primera linea debe ser como esto.
]$ w
 17:41:27 up 111 days,  8:58,  1 user,  load average: 0.19, 0.18, 0.18
On 13/01/2020 10:08 am, Romero, Fernando wrote:


De: Horacio Miranda [mailto:hmira...@gmail.com]
Enviado el: domingo, 12 de enero de 2020 05:42 p. m.
Para: Romero, Fernando; FORO POSTGRES
Asunto: Re: Consulta sobre DISCARD

Esta es la salida del comando w
USER TTY  FROM LOGIN@   IDLE   JCPU   PCPU WHAT
root pts/0xx   11:172:10m  7.37s  7.32s top
root pts/1xx  18:061.00s  0.01s  0.00s w
La base se pone muy lenta el cPU esta siempre al 100%

  PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND
13688 postgres  20   0 2350936 186424 126304 R 100.0  2.3  18:19.32 postgres
Saludos
On 13/01/2020 3:11 am, Romero, Fernando wrote:
Hola como están, alguien tienen experiencia con DISCARD?
Estoy teniendo problemas de perfomance cuando se ejecuta DISCARD me mata la 
base, me usa el 100% de la CPU.
A que llamas que te mata la base de datos ? ( se muere el proceso que maneja la 
base de datos o se pone lenta solamente ? ).
Sobre el uso de la CPU a que llamas 100% ? Cuantos cores tienes la salida del 
comando w ( que te dice ? ).  ( la primera linea es la imporatnte los ultimos 
nuemeros.

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 exp

Re: Consulta sobre DISCARD

[Horacio Miranda]

On 13/01/2020 2:32 pm, Romero, Fernando wrote:


Es un vps con 4 CPU y 8GB de memoria si swap

estas usando un 121 % de uan capacidad de 400%, es decir estas usando un 
30.25% de tu capacidad no estas usando el 100% de la CPU.


*De:*Enrique Kurth Schoenfeld Escobar [mailto:eku...@live.com.mx]
*Enviado el:* domingo, 12 de enero de 2020 07:45 p. m.
*Para:* Horacio Miranda; Romero, Fernando; pgsql-es-ayuda
*Asunto:* Re: Consulta sobre DISCARD

Hola..

Es virtual o física la maquina?.

Cuantas CPU tiene tu sistema ?

On 13/01/2020 10:30 am, Romero, Fernando wrote:

Ahí esta la primer línea no la había visto

De: Romero, Fernando [mailto:fernando.rom...@trenesargentinos.gob.ar]

Enviado el: domingo, 12 de enero de 2020 06:29 p. m.

Para: Horacio Miranda; FORO POSTGRES

Asunto: RE: Consulta sobre DISCARD

Estas son las únicas líneas que salen, será otro comando?

root@vm-1808948:~# w

18:28:01 up  7:12,  2 users,  load average: 1.21, 1.31, 1.33

USER     TTY      FROM             LOGIN@   IDLE   JCPU PCPU WHAT

root     pts/0    xx   11:17    2:32m  8.55s  8.50s top

root     pts/1    xx  18:28    1.00s  0.02s  0.00s w

root@vm-1808948:~#

De: Horacio Miranda [mailto:hmira...@gmail.com]

Enviado el: domingo, 12 de enero de 2020 06:19 p. m.

Para: Romero, Fernando; FORO POSTGRES

Asunto: Re: Consulta sobre DISCARD

La primera linea debe ser como esto.

]$ w

 17:41:27 up 111 days,  8:58,  1 user,  load average: 0.19, 0.18, 0.18

On 13/01/2020 10:08 am, Romero, Fernando wrote:

De: Horacio Miranda [mailto:hmira...@gmail.com]

Enviado el: domingo, 12 de enero de 2020 05:42 p. m.

Para: Romero, Fernando; FORO POSTGRES

Asunto: Re: Consulta sobre DISCARD

Esta es la salida del comando w

USER     TTY      FROM             LOGIN@   IDLE   JCPU PCPU WHAT

root     pts/0    xx   11:17    2:10m  7.37s  7.32s top

root     pts/1    xx  18:06    1.00s  0.01s  0.00s w

La base se pone muy lenta el cPU esta siempre al 100%

PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND

13688 postgres  20   0 2350936 186424 126304 R 100.0  2.3  18:19.32 
postgres


Saludos

On 13/01/2020 3:11 am, Romero, Fernando wrote:

Hola como están, alguien tienen experiencia con DISCARD?

Estoy teniendo problemas de perfomance cuando se ejecuta DISCARD me 
mata la base, me usa el 100% de la CPU.


A que llamas que te mata la base de datos ? ( se muere el proceso que 
maneja la base de datos o se pone lenta solamente ? ).


Sobre el uso de la CPU a que llamas 100% ? Cuantos cores tienes la 
salida del comando w ( que te dice ? ).  ( la primera linea es la 
imporatnte los ultimos nuemeros.


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”


“El contenido del presente mensaje (y sus anexos) es privado, 
confidencial y de exclusivo uso para el

RE: Consulta sobre DISCARD

[Romero, Fernando]

Es un vps con 4 CPU y 8GB de memoria si swap

De: Enrique Kurth Schoenfeld Escobar [mailto:eku...@live.com.mx]
Enviado el: domingo, 12 de enero de 2020 07:45 p. m.
Para: Horacio Miranda; Romero, Fernando; pgsql-es-ayuda
Asunto: Re: Consulta sobre DISCARD

Hola..
Es virtual o física la maquina?.

Cuantas CPU tiene tu sistema ?

On 13/01/2020 10:30 am, Romero, Fernando wrote:
Ahí esta la primer línea no la había visto

De: Romero, Fernando [mailto:fernando.rom...@trenesargentinos.gob.ar]
Enviado el: domingo, 12 de enero de 2020 06:29 p. m.
Para: Horacio Miranda; FORO POSTGRES
Asunto: RE: Consulta sobre DISCARD

Estas son las únicas líneas que salen, será otro comando?

root@vm-1808948:~# w
18:28:01 up  7:12,  2 users,  load average: 1.21, 1.31, 1.33
USER TTY  FROM LOGIN@   IDLE   JCPU   PCPU WHAT
root pts/0xx   11:172:32m  8.55s  8.50s top
root pts/1xx  18:281.00s  0.02s  0.00s w
root@vm-1808948:~#

De: Horacio Miranda [mailto:hmira...@gmail.com]
Enviado el: domingo, 12 de enero de 2020 06:19 p. m.
Para: Romero, Fernando; FORO POSTGRES
Asunto: Re: Consulta sobre DISCARD

La primera linea debe ser como esto.
]$ w
 17:41:27 up 111 days,  8:58,  1 user,  load average: 0.19, 0.18, 0.18
On 13/01/2020 10:08 am, Romero, Fernando wrote:


De: Horacio Miranda [mailto:hmira...@gmail.com]
Enviado el: domingo, 12 de enero de 2020 05:42 p. m.
Para: Romero, Fernando; FORO POSTGRES
Asunto: Re: Consulta sobre DISCARD

Esta es la salida del comando w
USER TTY  FROM LOGIN@   IDLE   JCPU   PCPU WHAT
root pts/0xx   11:172:10m  7.37s  7.32s top
root pts/1xx  18:061.00s  0.01s  0.00s w
La base se pone muy lenta el cPU esta siempre al 100%

  PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND
13688 postgres  20   0 2350936 186424 126304 R 100.0  2.3  18:19.32 postgres
Saludos
On 13/01/2020 3:11 am, Romero, Fernando wrote:
Hola como están, alguien tienen experiencia con DISCARD?
Estoy teniendo problemas de perfomance cuando se ejecuta DISCARD me mata la 
base, me usa el 100% de la CPU.
A que llamas que te mata la base de datos ? ( se muere el proceso que maneja la 
base de datos o se pone lenta solamente ? ).
Sobre el uso de la CPU a que llamas 100% ? Cuantos cores tienes la salida del 
comando w ( que te dice ? ).  ( la primera linea es la imporatnte los ultimos 
nuemeros.

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"
"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, a

Re: Consulta sobre DISCARD

[Horacio Miranda]

cat /proc/cpuinfo, cuantos threads tienes asignado a tu sistema.

por que 1 punto = 1 CPU.

si tienes 4 CPU para que sea 100% son 4 puntos en la primera linea... 
representa la carga de CPU en el queue, eso es el load average.



El sistemas hay dos conceptos, CPU latency y IO latency. si un proceso 
esta esperando la CPU con una CPU mas rapida o no caped anda mejor tu 
plataforma.


Si tienes problemas de IO block latency, con mas discos o separandos los 
IOPS anda mejor.


La Red la misma historia.

La memoria la misma historia.

Cuando hago clases de Linux es un de los temas que aclaro siempre, por 
que muchas personas al ver 100% no se dan cuenta que un proceso esta 
usando una sola CPU eso no es 100% de CPU en una plataforma.



On 13/01/2020 11:44 am, Enrique Kurth Schoenfeld Escobar wrote:

Hola..
Es virtual o física la maquina?.

Cuantas CPU tiene tu sistema ?

On 13/01/2020 10:30 am, Romero, Fernando wrote:
Ahí esta la primer línea no la había visto

De: Romero, Fernando [mailto:fernando.rom...@trenesargentinos.gob.ar]
Enviado el: domingo, 12 de enero de 2020 06:29 p. m.
Para: Horacio Miranda; FORO POSTGRES
Asunto: RE: Consulta sobre DISCARD

Estas son las únicas líneas que salen, será otro comando?

root@vm-1808948:~# w
18:28:01 up  7:12,  2 users,  load average: 1.21, 1.31, 1.33
USER     TTY      FROM             LOGIN@   IDLE   JCPU PCPU WHAT
root     pts/0    xx   11:17    2:32m  8.55s  8.50s top
root     pts/1    xx  18:28    1.00s  0.02s  0.00s w
root@vm-1808948:~#

De: Horacio Miranda [mailto:hmira...@gmail.com]
Enviado el: domingo, 12 de enero de 2020 06:19 p. m.
Para: Romero, Fernando; FORO POSTGRES
Asunto: Re: Consulta sobre DISCARD

La primera linea debe ser como esto.
]$ w
 17:41:27 up 111 days,  8:58,  1 user,  load average: 0.19, 0.18, 0.18
On 13/01/2020 10:08 am, Romero, Fernando wrote:


De: Horacio Miranda [mailto:hmira...@gmail.com]
Enviado el: domingo, 12 de enero de 2020 05:42 p. m.
Para: Romero, Fernando; FORO POSTGRES
Asunto: Re: Consulta sobre DISCARD

Esta es la salida del comando w
USER     TTY      FROM             LOGIN@   IDLE   JCPU PCPU WHAT
root     pts/0    xx   11:17    2:10m  7.37s  7.32s top
root     pts/1    xx  18:06    1.00s  0.01s  0.00s w
La base se pone muy lenta el cPU esta siempre al 100%

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM   TIME+ COMMAND
13688 postgres  20   0 2350936 186424 126304 R 100.0  2.3  18:19.32 
postgres

Saludos
On 13/01/2020 3:11 am, Romero, Fernando wrote:
Hola como están, alguien tienen experiencia con DISCARD?
Estoy teniendo problemas de perfomance cuando se ejecuta DISCARD me 
mata la base, me usa el 100% de la CPU.
A que llamas que te mata la base de datos ? ( se muere el proceso que 
maneja la base de datos o se pone lenta solamente ? ).
Sobre el uso de la CPU a que llamas 100% ? Cuantos cores tienes la 
salida del comando w ( que te dice ? ).  ( la primera linea es la 
imporatnte los ultimos nuemeros.


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

Re: Consulta sobre DISCARD

[Enrique Kurth Schoenfeld Escobar]

Hola..
Es virtual o física la maquina?.

Cuantas CPU tiene tu sistema ?

On 13/01/2020 10:30 am, Romero, Fernando wrote:
Ahí esta la primer línea no la había visto

De: Romero, Fernando [mailto:fernando.rom...@trenesargentinos.gob.ar]
Enviado el: domingo, 12 de enero de 2020 06:29 p. m.
Para: Horacio Miranda; FORO POSTGRES
Asunto: RE: Consulta sobre DISCARD

Estas son las únicas líneas que salen, será otro comando?

root@vm-1808948:~# w
18:28:01 up  7:12,  2 users,  load average: 1.21, 1.31, 1.33
USER TTY  FROM LOGIN@   IDLE   JCPU   PCPU WHAT
root pts/0xx   11:172:32m  8.55s  8.50s top
root pts/1xx  18:281.00s  0.02s  0.00s w
root@vm-1808948:~#

De: Horacio Miranda [mailto:hmira...@gmail.com]
Enviado el: domingo, 12 de enero de 2020 06:19 p. m.
Para: Romero, Fernando; FORO POSTGRES
Asunto: Re: Consulta sobre DISCARD

La primera linea debe ser como esto.
]$ w
 17:41:27 up 111 days,  8:58,  1 user,  load average: 0.19, 0.18, 0.18
On 13/01/2020 10:08 am, Romero, Fernando wrote:


De: Horacio Miranda [mailto:hmira...@gmail.com]
Enviado el: domingo, 12 de enero de 2020 05:42 p. m.
Para: Romero, Fernando; FORO POSTGRES
Asunto: Re: Consulta sobre DISCARD

Esta es la salida del comando w
USER TTY  FROM LOGIN@   IDLE   JCPU   PCPU WHAT
root pts/0xx   11:172:10m  7.37s  7.32s top
root pts/1xx  18:061.00s  0.01s  0.00s w
La base se pone muy lenta el cPU esta siempre al 100%

  PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND
13688 postgres  20   0 2350936 186424 126304 R 100.0  2.3  18:19.32 postgres
Saludos
On 13/01/2020 3:11 am, Romero, Fernando wrote:
Hola como están, alguien tienen experiencia con DISCARD?
Estoy teniendo problemas de perfomance cuando se ejecuta DISCARD me mata la 
base, me usa el 100% de la CPU.
A que llamas que te mata la base de datos ? ( se muere el proceso que maneja la 
base de datos o se pone lenta solamente ? ).
Sobre el uso de la CPU a que llamas 100% ? Cuantos cores tienes la salida del 
comando w ( que te dice ? ).  ( la primera linea es la imporatnte los ultimos 
nuemeros.

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”
“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

Re: Consulta sobre DISCARD

[Horacio Miranda]

Cuantas CPU tiene tu sistema ?


On 13/01/2020 10:30 am, Romero, Fernando wrote:


Ahí esta la primer línea no la había visto

*De:*Romero, Fernando [mailto:fernando.rom...@trenesargentinos.gob.ar]
*Enviado el:* domingo, 12 de enero de 2020 06:29 p. m.
*Para:* Horacio Miranda; FORO POSTGRES
*Asunto:* RE: Consulta sobre DISCARD

Estas son las únicas líneas que salen, será otro comando?

root@vm-1808948:~# w

18:28:01 up 7:12,  2 users,  load average: 1.21, 1.31, 1.33

USER TTY  FROM LOGIN@   IDLE   JCPU   PCPU WHAT

root pts/0    xx   11:17    2:32m  8.55s  8.50s top

root pts/1    xx  18:28    1.00s  0.02s  0.00s w

root@vm-1808948:~#

*De:*Horacio Miranda [mailto:hmira...@gmail.com]
*Enviado el:* domingo, 12 de enero de 2020 06:19 p. m.
*Para:* Romero, Fernando; FORO POSTGRES
*Asunto:* Re: Consulta sobre DISCARD

La primera linea debe ser como esto.

]$ w
 17:41:27 up 111 days,  8:58,  1 user,  load average: 0.19, 0.18, 0.18

On 13/01/2020 10:08 am, Romero, Fernando wrote:

*De:*Horacio Miranda [mailto:hmira...@gmail.com]
*Enviado el:* domingo, 12 de enero de 2020 05:42 p. m.
*Para:* Romero, Fernando; FORO POSTGRES
*Asunto:* Re: Consulta sobre DISCARD

Esta es la salida del comando w

USER TTY  FROM LOGIN@   IDLE   JCPU   PCPU WHAT

root pts/0    xx   11:17    2:10m  7.37s  7.32s top

root pts/1    xx  18:06    1.00s  0.01s  0.00s w

La base se pone muy lenta el cPU esta siempre al 100%

PID USER  PR  NI    VIRT    RES    SHR S  %CPU %MEM TIME+
COMMAND

13688 postgres  20   0 2350936 186424 126304 R 100.0  2.3 18:19.32
postgres

Saludos

On 13/01/2020 3:11 am, Romero, Fernando wrote:

Hola como están, alguien tienen experiencia con DISCARD?

Estoy teniendo problemas de perfomance cuando se ejecuta
DISCARD me mata la base, me usa el 100% de la CPU.

A que llamas que te mata la base de datos ? ( se muere el proceso
que maneja la base de datos o se pone lenta solamente ? ).

Sobre el uso de la CPU a que llamas 100% ? Cuantos cores tienes la
salida del comando w ( que te dice ? ).  ( la primera linea es la
imporatnte los ultimos nuemeros.

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”


“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

RE: Consulta sobre DISCARD

[Romero, Fernando]

Ahí esta la primer línea no la había visto

De: Romero, Fernando [mailto:fernando.rom...@trenesargentinos.gob.ar]
Enviado el: domingo, 12 de enero de 2020 06:29 p. m.
Para: Horacio Miranda; FORO POSTGRES
Asunto: RE: Consulta sobre DISCARD

Estas son las únicas líneas que salen, será otro comando?

root@vm-1808948:~# w
18:28:01 up  7:12,  2 users,  load average: 1.21, 1.31, 1.33
USER TTY  FROM LOGIN@   IDLE   JCPU   PCPU WHAT
root pts/0xx   11:172:32m  8.55s  8.50s top
root pts/1xx  18:281.00s  0.02s  0.00s w
root@vm-1808948:~#

De: Horacio Miranda [mailto:hmira...@gmail.com]
Enviado el: domingo, 12 de enero de 2020 06:19 p. m.
Para: Romero, Fernando; FORO POSTGRES
Asunto: Re: Consulta sobre DISCARD


La primera linea debe ser como esto.

]$ w
 17:41:27 up 111 days,  8:58,  1 user,  load average: 0.19, 0.18, 0.18
On 13/01/2020 10:08 am, Romero, Fernando wrote:


De: Horacio Miranda [mailto:hmira...@gmail.com]
Enviado el: domingo, 12 de enero de 2020 05:42 p. m.
Para: Romero, Fernando; FORO POSTGRES
Asunto: Re: Consulta sobre DISCARD


Esta es la salida del comando w

USER TTY  FROM LOGIN@   IDLE   JCPU   PCPU WHAT

root pts/0xx   11:172:10m  7.37s  7.32s top

root pts/1xx  18:061.00s  0.01s  0.00s w

La base se pone muy lenta el cPU esta siempre al 100%



  PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND

13688 postgres  20   0 2350936 186424 126304 R 100.0  2.3  18:19.32 postgres

Saludos
On 13/01/2020 3:11 am, Romero, Fernando wrote:
Hola como están, alguien tienen experiencia con DISCARD?
Estoy teniendo problemas de perfomance cuando se ejecuta DISCARD me mata la 
base, me usa el 100% de la CPU.

A que llamas que te mata la base de datos ? ( se muere el proceso que maneja la 
base de datos o se pone lenta solamente ? ).

Sobre el uso de la CPU a que llamas 100% ? Cuantos cores tienes la salida del 
comando w ( que te dice ? ).  ( la primera linea es la imporatnte los ultimos 
nuemeros.

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

RE: Consulta sobre DISCARD

[Romero, Fernando]

Estas son las únicas líneas que salen, será otro comando?

root@vm-1808948:~# w
18:28:01 up  7:12,  2 users,  load average: 1.21, 1.31, 1.33
USER TTY  FROM LOGIN@   IDLE   JCPU   PCPU WHAT
root pts/0xx   11:172:32m  8.55s  8.50s top
root pts/1xx  18:281.00s  0.02s  0.00s w
root@vm-1808948:~#

De: Horacio Miranda [mailto:hmira...@gmail.com]
Enviado el: domingo, 12 de enero de 2020 06:19 p. m.
Para: Romero, Fernando; FORO POSTGRES
Asunto: Re: Consulta sobre DISCARD


La primera linea debe ser como esto.

]$ w
 17:41:27 up 111 days,  8:58,  1 user,  load average: 0.19, 0.18, 0.18
On 13/01/2020 10:08 am, Romero, Fernando wrote:


De: Horacio Miranda [mailto:hmira...@gmail.com]
Enviado el: domingo, 12 de enero de 2020 05:42 p. m.
Para: Romero, Fernando; FORO POSTGRES
Asunto: Re: Consulta sobre DISCARD


Esta es la salida del comando w

USER TTY  FROM LOGIN@   IDLE   JCPU   PCPU WHAT

root pts/0xx   11:172:10m  7.37s  7.32s top

root pts/1xx  18:061.00s  0.01s  0.00s w

La base se pone muy lenta el cPU esta siempre al 100%



  PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND

13688 postgres  20   0 2350936 186424 126304 R 100.0  2.3  18:19.32 postgres

Saludos
On 13/01/2020 3:11 am, Romero, Fernando wrote:
Hola como están, alguien tienen experiencia con DISCARD?
Estoy teniendo problemas de perfomance cuando se ejecuta DISCARD me mata la 
base, me usa el 100% de la CPU.

A que llamas que te mata la base de datos ? ( se muere el proceso que maneja la 
base de datos o se pone lenta solamente ? ).

Sobre el uso de la CPU a que llamas 100% ? Cuantos cores tienes la salida del 
comando w ( que te dice ? ).  ( la primera linea es la imporatnte los ultimos 
nuemeros.

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"