Sisi, pasa que en el correo de Fernando, menciona que usa "auth_type = md5"
On 2025-07-01 16:04, Álvaro Herrera wrote:
Diego escribió:
Si mal no recuerdo, en pg15 ya el default de las claves es scram, por lo que
si utilizas |auth_type=md5,|el usuario que uses para el bouncer, vas a tener
que se
Diego escribió:
> Si mal no recuerdo, en pg15 ya el default de las claves es scram, por lo que
> si utilizas |auth_type=md5,|el usuario que uses para el bouncer, vas a tener
> que setearle la clave en md5
Hmm, pero pgbouncer soporta claves en SCRAM también:
https://www.crunchydata.com/blog/pgbounc
Si mal no recuerdo, en pg15 ya el default de las claves es scram, por lo
que si utilizas |auth_type=md5,|el usuario que uses para el bouncer, vas
a tener que setearle la clave en md5
On 2025-06-30 09:05, Romero, Fernando wrote:
Hola como estas Jose
Si ya tenes instalado pc-bouncer tenes que
Hola como estas Jose
Si ya tenes instalado pc-bouncer tenes que configurar el archivo pgbouncer.ini
que lo tenes en el directorio /etc/pgbouncer
Sino lo tenes instalado con apt install pgbouncer lo instalar
Un ejemplo del ini seria asi
[databases]
mibasededatos = host=127.0.0.1 port=5432 dbname=”
Jaime Casanova escribió:
> On Mon, Apr 21, 2025 at 10:00 AM Jairo Graterón wrote:
> >
> > Saludos, gracias por estar pendiente
> >
> > Efectivamente se ha estabilizado, era un problema con las actualizaciones
> > automáticas.
> >
> > dpkg-reconfigure -plow unattended-upgrades
> >
> >
> > Aunque d
Upgrade vs update.
Automatic updates está bien.
Upgrades hay que probar bien
Regards,
Horacio Miranda
> On 30 Apr 2025, at 3:46 PM, Jaime Casanova
> wrote:
>
> On Mon, Apr 21, 2025 at 10:00 AM Jairo Graterón wrote:
>>
>> Saludos, gracias por estar pendiente
>>
>> Efectivamente se ha esta
On Mon, Apr 21, 2025 at 10:00 AM Jairo Graterón wrote:
>
> Saludos, gracias por estar pendiente
>
> Efectivamente se ha estabilizado, era un problema con las actualizaciones
> automáticas.
>
> dpkg-reconfigure -plow unattended-upgrades
>
>
> Aunque debería existir una forma para que no afecte las
Hola Alberto, como lo solucionaste?
Saludos
De: alberto [mailto:albertocardenasc...@gmail.com]
Enviado el: lunes, 28 de abril de 2025 10:41
Para: Guillermo E. Villanueva
CC: Juan; pgsql-es-ay...@postgresql.org
Asunto: Re: log_statement no funciona
Hola Lista. Efectivamente el problema era la
Hola Lista. Efectivamente el problema era la libreria pgaudit. Sin embargo
pude solucionarlo y mantener funcionando la libreria y el colector de log
del sistema
Saludos y Gracias
El lun, 28 abr 2025 a las 8:11, Guillermo E. Villanueva (<
guillermo...@gmail.com>) escribió:
> entiendo que logging_
entiendo que logging_collector tiene que estar en *on *para registrar en
logs de postgres, ¿estará causando este comportamiento es la librería
pgaudit?
El vie, 25 abr 2025 a las 18:15, Juan ()
escribió:
> Hola alberto, tiene loguing_collector =on prueba con loguing_collector=off
>
> On Fri, Apr
Hola alberto, tiene loguing_collector =on prueba con loguing_collector=off
On Fri, Apr 25, 2025 at 12:17 PM alberto
wrote:
> Hola Lista, muy buenos días. Llevo varios días tratando de solucionar un
> problema y es el siguiente:
> Tengo la siguiente configuración para los log.
>
> shared_preload
Hola Alberto, es muy raro que si tienes log_min_duration_statement en -1 te
aparezca eso. ?Puedes poner una linea completa del log donde aparecen esos
SELECT?t, es para ver lo que escribe (formato, y otros detalles...)si no
puede exponer lo que tiene el SELECT puede poner reemplazar el SELECT por ,
Mira
postgres=# SHOW log_min_messages;
log_min_messages
--
notice
(1 row)
postgres=# SHOW log_min_duration_statement;
log_min_duration_statement
-1
(1 row)
postgres=# SHOW log_statement;
log_statement
---
none
(1 row)
postgres=#
El
Hola
> On 25 Apr 2025, at 11:49 AM, alberto wrote:
>
> Hola Daymel, gracias por responder.
> Hice lo que me señalas, pero siguen apareciendo las sentencias select. Y eso
> es lo que no quiero loguear, ya no se que hacer.
Estas seguro que se están aplicando los cambios? Quizás tengas algún err
Hola Daymel, gracias por responder.
Hice lo que me señalas, pero siguen apareciendo las sentencias select. Y
eso es lo que no quiero loguear, ya no se que hacer.
El vie, 25 abr 2025 a las 12:29, Daymel Bonne Solís ()
escribió:
> Hola Alberto:
>
> On 25 Apr 2025, at 8:45 AM, alberto wrote:
>
> Ho
Hola Alberto:
> On 25 Apr 2025, at 8:45 AM, alberto wrote:
>
> Hola Lista, muy buenos días. Llevo varios días tratando de solucionar un
> problema y es el siguiente:
> Tengo la siguiente configuración para los log.
>
> shared_preload_libraries = 'pgaudit'
> log_destination = 'csvlog'
> logging
Saludos, gracias por estar pendiente
Efectivamente se ha estabilizado, era un problema con las actualizaciones
automáticas.
dpkg-reconfigure -plow unattended-upgrades
[image: image.png]
Aunque debería existir una forma para que no afecte las actualizaciones a
postgresql.
El jue, 17 abr 2025 a
On Tue, Mar 4, 2025 at 5:25 PM Jairo Graterón wrote:
>
> Sospecho que también puede ser que las actualizaciones automáticas haga que
> se reinicie el servidor postgresql, voy a desactivarlo temporalmente.
>
Saludos,
Ha pasado más de un mes. Supongo que tu sistema ya se ha estabilizado.
¿Pudiste
Enrique, gracias por tu respuesta
en las pruebas que realicé, en el server a la ca la agrego en
postgresl.conf con el parámetro ssl_ca_file = '//ca.crt' eso no es
suficiente? acaso mi comando para generarla:
openssl req -new -x509 -days 365 -nodes -out ca.crt -keyout ca.key -subj
"/CN=root-ca
Gracias Juan. Probé eso y el problema persiste
Mi pregunta apunta mas a ver si hay alguien que lo haya podido hacer
funcionar con Let´s encrypt, ya que si me funcionó con certificados
autofirmados en ambos lados.
El lun, 10 mar 2025 a las 15:00, Juan ()
escribió:
> existe un comando update-ca-c
Copiaste primero tu certificado al directorio de certs?
Fíjate en tu distro puede ser /etc/certs o /usar/share/certs etc ...
Tal vez
sudo find / -iname "*cert* -type d
Te de una pista
Salu2
El lun, 10 de mar de 2025, 15:19, Guillermo E. Villanueva <
guillermo...@gmail.com> escribió:
> Gracias Ju
lo dice el log:
2025-03-10 15:29:18.093 CET [893999] [unknown]@[unknown] LOG: could not
accept SSL connection: tlsv1 alert unknown ca
debes agregar el CA como CA conocido
saludos
El 10-03-25 a las 13:36, Guillermo E. Villanueva escribió:
Buenas tardes! En los últimos días estuve trabajando
Dice que no conoce el CA.Agrega el CA de let’s encrypt a tu Linux o en un archivo donde conoce el CA de lets encrypt.Ahora estás usando TLS o quieres usar mTLS ? Regards,Horacio MirandaOn 11 Mar 2025, at 5:37 AM, Guillermo E. Villanueva wrote:Buenas tardes! En los últimos días estuve trabajando e
nt:* Tuesday, March 11, 2025 1:17:54 PM
> *To:* Gabriel Guillem Barceló Soteras
> *Cc:* Horacio Miranda ; pgsql-es-ayuda <
> pgsql-es-ay...@postgresql.org>
> *Subject:* Re: Autenticación TSL
>
> Hola Gabriel, gracias por tu respuesta, el postgres está en un ununtu,
> segui los
con la que emites los certificados *del cliente*.
>Puedes utilitzar la ruta tipo
> /etc/pki/ca-trust/source/anchors/
>como el paso 1.
>
>
> https://www.postgresql.org/docs/13/runtime-config-connection.html#RUNTIME-CONFIG-CONNECTION-SSL
>
>
>
> Aún así, recomiendo
Gracias Horacio, van mis respuestas.
El lun, 10 mar 2025 a las 16:37, Horacio Miranda ()
escribió:
> Dice que no conoce el CA.
> Agrega el CA de let’s encrypt a tu Linux o en un archivo donde conoce el
> CA de lets encrypt.
>
En el cliente o en el server?
> Ahora estás usando TLS o quieres usar
on.html#RUNTIME-CONFIG-CONNECTION-SSL
Aún así, recomiendo utilitzar otros esquemas de autenticación como Kerberos
(GSSAPI) para mantener las identidades centralizadas más facilmente.
From: Horacio Miranda
Date: Monday, 10 March 2025 at 20:38
To: Guillermo E. Villanueva
Cc: pgsql-es-ayuda
Subje
existe un comando update-ca-certificates cambia en cada distro
salu2
On Mon, Mar 10, 2025 at 2:00 PM Guillermo E. Villanueva <
guillermo...@gmail.com> wrote:
> Enrique, gracias por tu respuesta
> en las pruebas que realicé, en el server a la ca la agrego en
> postgresl.conf con el parámetro
Hola compañero.
Desafortunadamente no encuentro esas extensiones o como instalarlas, que
menciona el artículo.
Agradezco me puedan apoyar.
En jueves, 6 de marzo de 2025, 18:57:04 GMT-5, Horacio Miranda
escribió:
Google me dice esto. Puede que tengas que Implementar un plug-in.
To im
Google me dice esto. Puede que tengas que Implementar un plug-in.
To implement OTP (One-Time Password) for Google Cloud SQL PostgreSQL instances,
you can use built-in authentication with username and password or IAM database
authentication, and potentially integrate a 2FA solution like pg_otp or
hola Jose como estas
Lo que veo yo, por ahi estoy equivocado, en el comando ALTER TABLE dentro del
loop estás concatenando la cadena de comandos de ALTER TABLE sin una validación
de si es correcto.
Miraria un poco las condiciones, el pg_event_trigger_ddl_commands ommand_tag
devuelve un identifi
Normally, recovery will proceed through all available WAL segments, thereby
restoring the database to the current point in time (or as close as
possible given the available WAL segments). Therefore, a normal recovery
will end with a “file not found” message, the exact text of the error
message depe
Échale un vistazo a esta doc donde explica lo mismo que te comenté
anteriormente respecto de los timelines:
https://www.enterprisedb.com/docs/supported-open-source/barman/single-server-streaming/step04-restore/
El mié, 5 mar 2025 a las 22:41, kernel kernel ()
escribió:
> Pero no encuentra el fic
Pero no encuentra el fichero.history Es correcto?Y descomento las líneas del archive_comand ? Que pasa en las copias del barman si recupere a un timeline anterior? Tengo que borrar las copias y volver ha hacer una nueva copia completa?Alguna buena guía en castellano?Gracias!!!El 5 mar 2025, a las
El restore ha sido correcto, simplemente te queda ejecutar la función
pg_wal_replay_resume(), para que se levante la base de datos en modo
escritura. La línea de log donde buscaba el fichero .2.history es una
forma de identificar cual es el último timeline en la instancia.
El mié, 5 mar 202
Hola Jose, si entiendo bien lo que necesitas, esto lo vas a tener que hacer
llevando tú los metadatos de las tablas, pues acceder a *comand* (plano) del
la funcion *pg_event_trigger_ddl_commands* puede sercomplicado, pues como
dice la doc este campo es : "A complete representation of the command, i
El 05/03/2025 a las 15:46, Felipe Nicolas Alvarado Diaz escribió:
Hola,
Podrías adjuntar el comando que estás utilizando para recuperar, y que
te devuelve en el log de barman cuando lo ejecutas.
También podrías adjuntar que te devuelve el "barman check all" y
"barman list-backup all".
Salud
Hola,
Podrías adjuntar el comando que estás utilizando para recuperar, y que te
devuelve en el log de barman cuando lo ejecutas.
También podrías adjuntar que te devuelve el "barman check all" y "barman
list-backup all".
Saludos.
El mié, 5 mar 2025 a las 9:03, kernel () escribió:
> Hola,
>
> Est
Ahh, revisa los tipos de discos que tienes.
los discos si son menos de 2T del tipo gp2 tienen limites de IOPS y no son para
bases de datos.
los tipo GP3 son mejores y no tienen el mismo limite.
si realmente necesitas mayor IOPS puedes usar unos mas caros, 3 veces mas caros
los io2 o io1.
Aho
Es una instancia EC2 de aws.
probaré sar.
Gracias.
El mar, 4 mar 2025 a las 19:34, Horacio Miranda ()
escribió:
> Si tienes instalado sar, usar sar -w
> esto te da la información del swap. para ver otros dias. /var/log/sa/ hay
> archivos.
> sar -w -f FILE
>
> ahora si no tienes un sistema de mo
Si tienes instalado sar, usar sar -w
esto te da la información del swap. para ver otros dias. /var/log/sa/ hay
archivos.
sar -w -f FILE
ahora si no tienes un sistema de monitoreo creo que datadog soporta un numero
de maquinas gratis, junto con new relic, eh usado ambas en el pasado y cada una
Extrañamente no volvimos a tener el problema de lentitud!!! fue solo ese
día y nunca mas!!
De todas maneras hice un script que lo dejo acá por si a alguien le sirve,
tomando la sugerencia de Horacio.
#!/bin/bash
TMP_FILE="/tmp/explain_tmp_$$.log"
LOG_FILE="/home/postgres/data/test.log"
START_TIM
Barman
100% recomendado
El mié, 19 feb 2025 a las 9:38, kernel () escribió:
> Gracias por las explicaciones, he tenido que hacer un resetwal y
> restaurar una copia
>
> Voy a interesarme por el barman
>
> Gracias por vuestro tiempo!!!
>
> El 19/02/2025 a las 9:36, Martín Marqués escribió:
> > El
que bueno , yo te recomiendo usar barman porque puedes mantener tus backup
físicos con lineas base con sus wal obviamente y te permite hacer PITR, y
su configuración es simple
Sldos.,
El mié, 19 feb 2025 a las 9:38, kernel () escribió:
> Gracias por las explicaciones, he tenido que hacer un res
Gracias por las explicaciones, he tenido que hacer un resetwal y
restaurar una copia
Voy a interesarme por el barman
Gracias por vuestro tiempo!!!
El 19/02/2025 a las 9:36, Martín Marqués escribió:
El mar, 18 feb 2025 a las 19:33, Fernando Monjes
() escribió:
Si tienes barman si se pueden re
Porque no usa auto_explain que escribe en el log el query plan? En ese
case, sabrias exactamente que plan se uso y de ahi ver si hace falta
un indice, o a lo mejor la consulta debe optimizarse de otra manera.
Igualmente, la optimizacion que estan buscando se llama "Upgrade" como
ya dijo Alvaro.
E
Buenas,
El mar, 18 feb 2025 a las 19:58, Byron Gallardo () escribió:
>
> si tienes algún respaldo tendrás que tratar de recuperar de ahí, sino,
> tendrias que probar con /usr/pgsql-14/bin/pg_resetwal -f
> /var/lib/pgsql/14/data/
> esto reinicia el WAL, eliminando cualquier referencia a los regi
El mar, 18 feb 2025 a las 19:33, Fernando Monjes
() escribió:
>
> Si tienes barman si se pueden recuperar los wal, puedes hacer PITR esa es la
> gran maravilla de barman
>
> ejemplo
> barman recover number --remote-ssh-command "ssh postgres@ "
> --target-time="2021-03-22 03:22:47.681236-03:00"
Puedes ver en pg_stat_statement como esa query esta usando la cache, si
tiene un alto % de utilizacion de la cache es muy seguro que la utilization
del IO no la affecte.
Si no la tienes instalada hay otras maneras de revisar como estas usando la
cache al nivel de base de datos en pg_stat_database.
Ojo, con ese script que corre la misma consulta cada min. y no tienes problemas
de velocidad me podría indicar que tal vez sea un tema de cache de la consulta,
que la saca de la RAM ( cache ).
Si la consulta no corre por un buen rato y se saca del cache, al correrla
fresca se podría demorar.
si tienes algún respaldo tendrás que tratar de recuperar de ahí, sino,
tendrias que probar con /usr/pgsql-14/bin/pg_resetwal -f
/var/lib/pgsql/14/data/ esto *reinicia el WAL*, eliminando cualquier
referencia a los registros antiguos y permitiendo que PostgreSQL arranque
con lo que tenga en el disc
Si tienes barman si se pueden recuperar los wal, puedes hacer PITR esa es
la gran maravilla de barman
ejemplo
barman recover number --remote-ssh-command "ssh postgres@ "
--target-time="2021-03-22 03:22:47.681236-03:00" /var/lib/pgsql/15/data
y te recupera esa linea de tiempo con los wal hasta
Hola!
Tenés un resguardo de los wal en otra ubicación ? (barman? pitr? algo?)
El mar, 18 feb 2025 a las 8:35, kernel () escribió:
> Hola,
>
> tengo un postgresql 16 ,accidentalmente se han borrado los archivos
> WAL, ahora no me arranca el postgresql, no se si hay algun tipo de
> solucion, entie
Extrañamente hoy la query anduvo bien, ya tengo armado el script sugerido
por Horacio pero por ahora no hay demoras.
Si hay demora, me va a dejar el plan en un log y se los muestro.
Muchas gracias!
El mar, 18 feb 2025 a las 12:41, Carlos T. Groero Carmona (<
cton...@gmail.com>) escribió:
> Guill
Guillermo, si logras capturar el plan y comparar, revisa el plan mode que
te comente, a mi me paso recientemente en la version 14, despues de
ejecutar la misma query con los mismos valores mas de 10 veces, la query
empieza a correr ridiculamente despacio, una query que corre desde mi
laptop en 85ms
Es buena idea Horacio, voy a armarla bien y luego les comento.
Muchas gracias.
El mar, 18 feb 2025 a las 6:38, Horacio Miranda ()
escribió:
> Y hacer un script que guarde el explain (buffers,analyze) select … cuando
> el time se demore mas de 10 segundos ?
>
> Lo corres a cada rato y de esa forma
Así es Alvaro, es demasiado vieja la versión, lamentablemente es un
problema que apareció ahora y está provocando importantes cuellos de
botella en el organismo en el que estoy. El pg17 va a demorar un poco en
implementarse porque hay factores externos (proveedor de sistema).
De todas maneras mucha
Guillermo E. Villanueva escribió:
> Buenas tardes, antes que nada, estoy usando una versión muy vieja de
> postgres por cuestiones contractuales y de un desarrollo de terceros, el
> proceso de upgrade a postgres 17 ya está iniciado, mientras tanto tengo un
> entorno de un postgres 9.2 con un master
Y hacer un script que guarde el explain (buffers,analyze) select … cuando el
time se demore mas de 10 segundos ?
Lo corres a cada rato y de esa forma capturas el plan malo vs el plan bueno ?
Algo como Lo dejas corriendo en el crontab, sera un poco pesado pero puede
darte luces del plan que e
Gracias por tu comentario, si puse la query, no usa prepare, va directo.
El El lun, 17 feb 2025 a la(s) 23:57, Carlos T. Groero Carmona <
cton...@gmail.com> escribió:
> Si, si estas usando prepared statements puede pasar, recisa esto:
> plan_cache_mode
>
> El valor por default is auto, trata de
Si quieres ajusta el sar para tomar muestras de 1 min para descartar que los
discos estén saturados.
Sobre la versión vieja de postgresql hace un set de pruebas debería funcionar
bien con claves tipo password y hasta la versión 13 si usas jdbc donde las
consultas mal hechas tiene el where pega
suponía que si!! puede tener diferentes planes para la misma query , mismos
valores? solo cambia el cliente
El lun, 17 feb 2025 a las 16:59, Carlos T. Groero Carmona (<
cton...@gmail.com>) escribió:
> Te da differentes planes y tiempo de ejecucion si la corres desde la
> applicacion y otro muy di
Te da differentes planes y tiempo de ejecucion si la corres desde la
applicacion y otro muy differente si lo ejecutas desde psql por ejemplo?
Regards,
Carlos
On Mon, Feb 17, 2025, 1:48 PM Guillermo E. Villanueva <
guillermo...@gmail.com> wrote:
> Buenas tardes, antes que nada, estoy usando una v
: Romero, Fernando
CC: Byron Gallardo; pgsql-es-ay...@postgresql.org
Asunto: Re: Consulta pg_hba.conf
CUIDADO: Este correo es externo a TRENES ARGENTINOS, no abras vinculos ni
completes formularios de origenes desconocidos.
Romero, Fernando escribió:
> postgres@pgda:/etc/postgresql/13/main$ p
, Fernando
Enviado: martes, 11 de febrero de 2025 14:59
Para: Ramón Alberto Bruening Gonzalez
Cc: pgsql-es-ay...@postgresql.org
Asunto: RE: Consulta pg_hba.conf
Asi tampoco funciona
# TYPE DATABASEUSERADDRESS METHOD
# "local" is for Unix dom
Hola Fernando, revisa el fichero postgresql.conf, que listenaddresses esté
activo con localhost
Saludos
De: Romero, Fernando
Enviado: martes, 11 de febrero de 2025 14:02
Para: Anthony Sotolongo
Cc: pgsql-es-ay...@postgresql.org
Asunto: RE: Consulta
Romero, Fernando escribió:
> postgres@pgda:/etc/postgresql/13/main$ psql
> psql (13.16 (Debian 13.16-0+deb11u1))
> Digite «help» para obtener ayuda.
Pues aquí el psql te funcionó perfectamente. Y nunca mostraste el psql
que fallaba.
--
Álvaro Herrera 48°01'N 7°57'E — https://www
: Álvaro Herrera; pgsql-es-ay...@postgresql.org
Asunto: RE: Consulta pg_hba.conf
postgres@pgda:/etc/postgresql/13/main$ psql
psql (13.16 (Debian 13.16-0+deb11u1))
Digite «help» para obtener ayuda.
postgres=# show hba_file ;
hba_file
-
/etc/postgresql
--
> *De:* Romero, Fernando
> *Enviado:* martes, 11 de febrero de 2025 14:59
> *Para:* Ramón Alberto Bruening Gonzalez
> *Cc:* pgsql-es-ay...@postgresql.org
> *Asunto:* RE: Consulta pg_hba.conf
>
>
> Asi tampoco funciona
>
>
>
> # TYPE DATABASEUSER
Asunto: Re: Consulta pg_hba.conf
CUIDADO: Este correo es externo a TRENES ARGENTINOS, no abras vinculos ni
completes formularios de origenes desconocidos.
dale un show hba_file ; en la consola psql para asegurar que estas editando el
correcto
Saludos
El mar, 11 feb 2025 a las 10:58, Romero
--
> De: Álvaro Herrera [mailto:alvhe...@alvh.no-ip.org]
> Enviado el: martes, 11 de febrero de 2025 10:45
> Para: Romero, Fernando
> CC: pgsql-es-ay...@postgresql.org
> Asunto: Re: Consulta pg_hba.conf
>
> CUIDADO: Este correo es externo a TRENES ARGENTINOS, no abras vinculos ni
Romero, Fernando escribió:
> Es el único pg_hba.conf que tiene el servidor
Entonces estás mirando el servidor equivocado.
--
Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/
g Gonzalez [mailto:albertobruen...@hotmail.com]
Enviado el: martes, 11 de febrero de 2025 10:56
Para: Romero, Fernando
CC: pgsql-es-ay...@postgresql.org
Asunto: Re: Consulta pg_hba.conf
CUIDADO: Este correo es externo a TRENES ARGENTINOS, no abras vinculos ni
completes formularios de origenes de
Es el único pg_hba.conf que tiene el servidor
-Mensaje original-
De: Álvaro Herrera [mailto:alvhe...@alvh.no-ip.org]
Enviado el: martes, 11 de febrero de 2025 10:45
Para: Romero, Fernando
CC: pgsql-es-ay...@postgresql.org
Asunto: Re: Consulta pg_hba.conf
CUIDADO: Este correo es externo a
# "local" is for Unix domain socket connections only
local all all trust --->
peer (debe ser)
El mar, 11 feb 2025 a las 9:37, Romero, Fernando (<
fernando.rom...@trenesargentinos.gob.ar>) escribió:
> Hola como están, tengo un error de autentifica
; Anthony Sotolongo
Cc: pgsql-es-ay...@postgresql.org
Asunto: RE: Consulta pg_hba.conf
Hola Javier, lo tengo para todos los hosts, tengo replicación
listen_addresses = '*'
Saludos
De: Javier Jimenez Matilla [mailto:jjmati...@coviran.es]
Enviado el: martes, 11 de febrero de 202
Hola Javier, lo tengo para todos los hosts, tengo replicación
listen_addresses = '*'
Saludos
De: Javier Jimenez Matilla [mailto:jjmati...@coviran.es]
Enviado el: martes, 11 de febrero de 2025 10:43
Para: Romero, Fernando; Anthony Sotolongo
CC: pgsql-es-ay...@postgresql.org
Asunto: RE
Romero, Fernando escribió:
> Hola como están, tengo un error de autentificación..
> Estoy haciendo unas pruebas en un server de testing, tengo todo en el
> pg_hba.conf en trust pero igual me tir error de autentificación
> psql: error: FATAL: la autentificación Peer falló para el usuario «xxx»
>
Hola Anthony, hice un restart.
Saludos
De: Anthony Sotolongo [mailto:asotolo...@gmail.com]
Enviado el: martes, 11 de febrero de 2025 09:42
Para: Romero, Fernando
CC: pgsql-es-ay...@postgresql.org
Asunto: Re: Consulta pg_hba.conf
CUIDADO: Este correo es externo a TRENES ARGENTINOS, no abras
Hola Fernando, ¿hiciste un reload?
saludos
El mar, 11 feb 2025 a las 9:37, Romero, Fernando (<
fernando.rom...@trenesargentinos.gob.ar>) escribió:
> Hola como están, tengo un error de autentificación..
>
> Estoy haciendo unas pruebas en un server de testing, tengo todo en el
> pg_hba.conf en tru
Muchas gracias por todo!!
El jue, 6 feb 2025 a las 11:12, Álvaro Herrera ()
escribió:
> Guillermo E. Villanueva escribió:
> > Muchas gracias Alvaro, tremendo crack ud.
> > Luego de ejecutar (en un ambiente de testing)
> >
> > ALTER TABLE companies ALTER id SET STATISTICS 1;
> >
> > ALTER TABL
Guillermo E. Villanueva escribió:
> Muchas gracias Alvaro, tremendo crack ud.
> Luego de ejecutar (en un ambiente de testing)
>
> ALTER TABLE companies ALTER id SET STATISTICS 1;
>
> ALTER TABLE companies ALTER fulldate SET STATISTICS 1;
>
> ANALYZE companies;
> El explain de la query en
Muchas gracias Alvaro, tremendo crack ud.
Luego de ejecutar (en un ambiente de testing)
ALTER TABLE companies ALTER id SET STATISTICS 1;
ALTER TABLE companies ALTER fulldate SET STATISTICS 1;
ANALYZE companies;
El explain de la query en cuestión cambió totalmente
Ahora si utiliza primero
Hola Horacio gracias por tu rta.
1)
Ejecuté los set para
random_page_cost = 4
effective_io_concurrency = 2
No hubo mejora. El plan sigue siendo el mismo
2)
Ejecuté analyze para todas las tablas
No hubo mejora. El plan sigue siendo el mismo
3)
No hice la conversión to_timestamp por que lo está t
Guillermo E. Villanueva escribió:
> Alvaro te copio el resultado acá:
> id 101
> subclient_id 101 100
> hidden_by_contact 101 6
> fulldate 101
OK, quizás te sirva tomar más estadísticas para id y fulldate.
ALTER TABLE companies ALTER id SET STATISTICS 1;
ALTER TABLE companies ALTER fulldate SE
Alvaro te copio el resultado acá:
id 101
subclient_id 101 100
hidden_by_contact 101 6
fulldate 101
title 101 33
pointers 101 100
page_num 101 100
eurl 11
url 101 1
ep_file 101
epoch_time 101 36
add_type 10 15
alt_title 101 10
views 12 6
box 8 23
vp 101 100
clip_ratio 101 2
clip_area 101
tirada 101
Hola, esta parte revisa si lo puedes trabajar, los filtros son después de una
lectura de disco o indices para reducir la lectura puedes crear un indice con
los filtros.
Index Cond: ((fulldate >= '2025-01-31 09:30:00'::timestamp without time zone)
AND (fulldate < '2025-02-04 09:30:00'::timestamp
Guillermo E. Villanueva escribió:
> Hola Alvaro cómo estas?
> Los índices de los que hablo tienen unos 27GB cada uno
> La tabla tiene unos 1.4TB
>
> effective_cache_size = 48GB
> shared_buffers = 24GB
¿y qué dice esto?
select attname, cardinality(histogram_bounds), cardinality(most_common_freqs)
Gracias.
Lo sigue planificando mal con ese random_page_cost
El mié, 5 feb 2025 a las 11:13, Jairo Graterón ()
escribió:
> Buen día
>
> prueba modificando ésta variable (al ejecutar en psql sólo lo modifica la
> sesión actual)
>
> set random_page_cost=1.0;
>
> y luego el explain original.
>
> Sa
Buen día
prueba modificando ésta variable (al ejecutar en psql sólo lo modifica la
sesión actual)
set random_page_cost=1.0;
y luego el explain original.
Saludos.
El mié, 5 feb 2025 a las 8:35, Guillermo E. Villanueva (<
guillermo...@gmail.com>) escribió:
> Hola Alvaro cómo estas?
> Los índic
Hola Alvaro cómo estas?
Los índices de los que hablo tienen unos 27GB cada uno
La tabla tiene unos 1.4TB
effective_cache_size = 48GB
shared_buffers = 24GB
El mié, 5 feb 2025 a las 9:13, Álvaro Herrera ()
escribió:
> Guillermo E. Villanueva escribió:
> > Jaja si engaño a pg y cambio la condición
Guillermo E. Villanueva escribió:
> Jaja si engaño a pg y cambio la condición
> and companies.fulldate::text >= '2025-01-31 09:30' and companies.fulldate::
> text < '2025-02-04 09:30'
>
> ya no usa el índice secundario, usa el índice de la PK y resuelve la query
> en menos de un segundo , lo tengo
Jaja si engaño a pg y cambio la condición
and companies.fulldate::text >= '2025-01-31 09:30' and companies.fulldate::
text < '2025-02-04 09:30'
ya no usa el índice secundario, usa el índice de la PK y resuelve la query
en menos de un segundo , lo tengo resuelto así pero me quedo con la duda de
por
https://explain.depesz.com/s/R3Fh
Si lo ejecuto solo hasta el filtro de companies.id devuelve el resultado en
menos de 1 segundo
Ese campo es PK de la tabla companies, si lo resuelve tan rápido al de las
PK porque priorizar un indice de la misma tabla donde las columnas no son
PK?
El mar, 4 feb 2
Es de tipo integer
probé con "companies"."id" = ANY (ARRAY[1381059542::integer, 1380939758::
integer, 1380939757::integer, 1380939753::integer])
pero lo sigue poniendo como filtro dentro de la búsqueda de otro indice que
no es PK
El mar, 4 feb 2025 a las 19:49, Jairo Graterón ()
escribió:
> Salu
Usa depez para compartir el plan de ejecución por favorNew explain | explain.depesz.comexplain.depesz.comUsa esta forma explain (analyze,buffers) select ..Regards,Horacio MirandaOn 5 Feb 2025, at 11:49 AM, Jairo Graterón wrote:Saludosid es de tipo int o bigint?Prueba con esta otra forma de hacer
Saludos
id es de tipo int o bigint?
Prueba con esta otra forma de hacer el IN y nos comentas.
"companies"."id" = ANY (ARRAY[1381059542, 1380939758, 1380939757,
1380939753]::integer)
si es tipo bigint
"companies"."id" = ANY (ARRAY[1381059542, 1380939758, 1380939757,
1380939753]::bigint[])
E
Hola, si estas usando la version 17, creo que agregaron algo en el
pg_dump/pg_restore para eso, un parametro llamado --filter
https://www.postgresql.org/docs/17/app-pgdump.html
https://www.postgresql.org/docs/17/app-pgrestore.html
de lo contrario puede que tengas que jugar con los parametris
Podrias sacar un respaldo sin los datos y otro respaldo de los datos solamente.
el respaldo sin datos lo editas y sacar lo que quieres sacar.
lo otro es leer un poco en internet debe haber un proceso. Si tu no lees,
alguien lo va a leer por ti y contarte como se hace.
> On 20 Dec 2024, at 10:53
Entendido, respecto al fichero, esto no es problema aunque tengo otra opinión.
Por otro lado me ha gustado el símil, tranquilo no me ofendo nada si te metes
con windows la verdad, aunque más que un mueble veo postgres como el lugar
donde está tú fortuna y suelen existir cajas fuertes dentro de
1 - 100 of 1129 matches
Mail list logo
