Re: Backup postgres
Fredy Hurtado escribió: > Buenas tardes, > > Estoy generando un backup en Postgres 15.7 sobre Debian 12 y al momento de > lanzarlo, me aparece este error: > > pg_dump: error: la consulta falló: ERROR: no se pudo leer el bloque 0 del > archivo «base/36094/3119»: Error de entrada/salida Ese error viene del sistema operativo, y muy probablemente indica que uno de tus discos está muriendo. 3119 es un índice en el catálogo de sistema pg_foreign_table. Quizás puedas recuperar esto haciendo REINDEX TABLE pg_foreign_table en la base de datos afectada, aunque nunca se puede saber si no tienes corrupción en alguna otra parte, especialmente en archivos con datos de tabla. Recomendaría que saques tus datos de esa máquina, o de ese disco, para restaurarlos en una máquina confiable, antes de seguir operando. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ "La vida es para el que se aventura"
Re: Creación de una replica adicional
Horacio Miranda escribió: > Hola cual es la retención que tienes del wall ? > > |wal_keep_size es un valor que deberias ajustar para poder retener los wall > necesarios para replicar ambos targets. Eso no es relevante; no es responsabilidad del primario guardar el WAL. Por eso está la opción -Xs de pg_basebackup. -- Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/ "This is a foot just waiting to be shot"(Andrew Dunstan)
Re: Creación de una replica adicional
Hola, Elizabeth Fernandez escribió: > El comando que he utilizado para la creacion de la replica es: > pg_basebackup -h -p 5432 -D -U -Fp -P > -v -R -Xs --checkpoint=fast -C -S > Hasta ahora cuando lo he utilizado ha funcionado. Esta semana traté de > crear la 2da replica, pero cuando finalizó el pg_basebackup y se ejecutó el > start de la base de datos, el log indica que requiere hacer el streaming de > un WAL del servidor primario y el mismo ya fue eliminado. Hmm, el problem NO es que el WAL haya sido eliminado, porque el archivo ya está en el pg_wal de la réplica. El problema es que al leer ese WAL que estaba en la réplica, ocurrió este error: > 2024-08-15 06:42:40.087 EDT [127391] LOG: incorrect resource manager data > checksum in record at 53A7/4570AA10 Por alguna razón, el nuevo servidor no está interpretando correctamente el WAL. ¿Son paquetes de la misma fuente, de la misma versión, en el mismo sistema operativo? (El mensaje de que el WAL ya fue eliminado, lo lanza porque una vez que ocurre la primera falla, el standby no sabe qué más hacer aparte de pedirle al primario que le envíe el WAL nuevamente; pero eso ya sabemos que va a fallar, porque el primario no guarda todos esos días de WAL. La opción -Xs de pg_basebackup se hace cargo de traer todo el WAL desde el primario y ponerlo en el pg_wal de la réplica, antes de que el primario lo borre.) ¿Tienes algún módulo o extensión que pudiera estar publicando WAL no estándar? Podrías intentar hacer pg_waldump de ese segmento en la réplica, si es que todavía tienes el archivo. -- Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/
Re: PSQL Dockerizado Productivo?
Federico Pascual escribió: > No había escuchado experiencias de gente que utilice motores de base de > datos en contenedores en entornos productivos; si otro tipo de > infraestructura (aplicaciones). Es nuevo. Por ejemplo la iniciativa "Data on Kubernetes" es relativamente nueva comparada con tener K8s para aplicaciones "stateless". https://dok.community/ Recomiendo darle una mirada a este: https://github.com/cloudnative-pg/cloudnative-pg -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
Re: Archivado particularmente voluminoso.
Hola Federico Pascual escribió: > Tenemos una db que está generando una gran cantidad de archivado. Esto es > que el archivado para un día en particular es muy voluminoso en comparación > con lo que ocupa la db. > En los logs tenemos por ejemplo la siguiente info: > > 2024-05-27 22:06:17.353 -03 [2302] LOG: empezando checkpoint: time > 2024-05-27 22:11:17.128 -03 [2302] LOG: empezando checkpoint: time > 2024-05-27 22:16:17.078 -03 [2302] LOG: empezando checkpoint: time Esto evidencia que tienes checkpoint_timeout=5min, que es el valor por omisión. Quizás podrías cambiarlo a 20min o algo así, lo cual podría disminuir la cantidad de WAL que se escribe y por lo tanto que se archiva. > 2024-05-27 22:20:46.803 -03 [2302] LOG: checkpoint completado: se escribió > 2690 buffers (0.8%); 0 archivo(s) WAL añadido(s), 0 eliminado(s), 3 > reciclado(s); escritura=269.697 s, sincronización=0.005 s, total=269.726 s; > archivos sincronizados=213, más largo=0.004 s, promedio=0.001 s; > distancia=46373 kB, estimado=50915 kB Acá se reciclaron 3 segmentos de WAL, que son 48 MB; en todos tus checkpoints parece ser la misma cantidad. No me parece un número gigante la verdad ... digamos que es bastante modesto. Prueba a hacer "pg_waldump -z" para mostrar un resumen por tipo de resource manager y full-page writes del tráfico de WAL. Si los FPW (o FPI) son mayoría, entonces hacer menos checkpoints debido a cambiar el timeout podría disminuir mucho el tráfico total de WAL también. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
Re: Estabilidad de la API interna
Mario González Troncoso escribió: > Si funciona para 16.1, va a seguir funcionando para todas las 16.X que > vengan. Aun mas, *podria* funcionar en las siguientes (Incluso > anteriores) si es que las bibliotecas de libpq por ejemplo que estés > usando mantengan la misma funcionalidad o no hayan cambiado el > "signature" en las funciones. A medida de que tu extensión no se > actualice a versiones futuras, digamos v18 o mayor, menor va a ser la > certeza de que vaya a funcionar. En esos casos, IMO siempre es mejor > volver a compilar y/o tener versiones para diferentes ramas. No realmente -- entre cambios de versiones mayores, siempre tienes que recompilar. Esto es porque Postgres verifica que cada módulo que carga tenga un bloque PG_MODULE_MAGIC, el cual incluye un número de versión mayor; y se verifica que ese número de la biblioteca coincida con la versión del servidor. Es cierto que la recompilación puede ser limpia (es decir no necesitar ningún cambio). Sobre la pregunta de Daymel. La ABI dentro de versiones *menores* se trata de mantener lo más posible, y si bien todavía no tenemos herramientas que lo verifiquen automáticamente, los committers son muy cuidadosos en no introducir cambios, y cada vez hay más revisión de que ese requisito se cumpla. Por ejemplo en vez de cambiar la signatura de funciones existentes, se prefiere agregar funciones adicionales cuando ese necesario tener más argumentos o distintos; si hay que agregar miembros a structs, se hace al final; si los structs se usan en arrays no se pueden agregar miembros al final, se agregan structs separados para lo que sea que necesites; los valores de los enums no se reenumeran; y cosas así. Como el PG_MODULE_MAGIC protege de que un módulo compilado para una versión mayor anterior no funcione con una versión mayor nueva, todos esos cambios se pueden hacer con tranquilidad en la rama master. -- Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/ Are you not unsure you want to delete Firefox? [Not unsure] [Not not unsure][Cancel] http://smylers.hates-software.com/2008/01/03/566e45b2.html
Re: borrar y generar nuevamente cluster
Guillermo E. Villanueva escribió: > Buen día estoy haciendo unas pruebas en ubuntu 22.04.2 y postgres 16. > La instalación de postgres 16 siguiendo los pasos de > https://www.postgresql.org/download/linux/ubuntu/ funciona perfecto. > Este paquete deja instalado el postgres como un servicio en el sistema > operativo, deja el usuario postgres ya creado y cluster main creado. > La pregunta es: ¿Es posible generar nuevamente el cluster main sin volver > instalar postgres y que queden funcionando las configuraciones (systemd, > usuario, etc) que la instalación hace? Debian/Ubuntu tienen un sistema propio de gestion de clústers (que si no entiendo mal viene en el paquete postgresql-common), que permiten múltiples clusters en múltiples versiones de Postgres corriendo simultáneamente, para lo cual se usan los programas pg_createcluster, pg_lsclusters, pg_dropcluster, pg_ctlcluster. Te recomiendo familiarizarte con ellos y usarlos para estas tareas, en lugar de tocar los directorios de datos manualmente. -- Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/ "Las cosas son buenas o malas segun las hace nuestra opinión" (Lisias)
Re: Costes en subconsulta sencilla
Ruben Fitó escribió:
> Tengo la siguiente query en postgresql que tiene un coste de casi un minuto:
>
> EXPLAIN
> SELECT
> mtx.oper_tipus,
> mtx.oper_estat
> FROM
> m_transaccions mtx
> INNER JOIN comm_pax_transactions pax ON (mtx.num_operacio = pax.num_oper)
> WHERE
> mtx.estacio = 333
> AND mtx.oper_tipus IN ('F', 'f', 'P', 'p')
> AND mtx.oper_estat IN (0, 1)
> AND mtx.num_operacio >
> *COALESCE(( SELECT num_oper_end FROM
> m_closures WHERE station = 333 ORDER BY id DESC
> LIMIT 1), 0 )*;
¿Probaste extrayendo el num_oper_end en una CTE?
WITH oper_end AS (select num_oper_end from m_closures ...)
select ...
from m_transaccions
inner join comm_pax_transactions ...
where mtx.num_operacio > coalesce( select bla from oper_end, 0);
Mira el explain y en caso de que Postgres decida volver el CTE como
parte de la consulta principal, prueba poniéndole MATERIALIZED al WITH
oper_end.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
Re: Configuración correcta de cron en Barman y mailes molestos.
Guillermo E. Villanueva escribió: > Mario, muchas gracias por tu respuesta, lo que me dices es que es parte de > crontab del sistema operativo y no de cron (procesos de barman) ? Un buen script de cron tiene que saber leer el resultado de lo que se ejecuta, y si todo termina bien, guardar el log silenciosamente sin mandar nada por mail; y si termina mal, mandar el log por mail para que el admin sepa que algo anda mal y que debe revisarse. Puede ser algo tan simple como 8<8<8<8<- #!/bin/sh set -e templog=$(mktemp) trap "rm $templog" 0 /usr/bin/barman backup eprensa > $templog if [ $? == 0 ]; then exit 0 else cat $templog fi 8<8<8<8<- y luego en el cron invocas con algo como MAILTO=guillermo...@gmail.com 0 14 * * 4 /home/guillermovil/bin/script_de_alvherre.sh -- Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/ "The eagle never lost so much time, as when he submitted to learn of the crow." (William Blake)
Re: lista de stopwords
Anthony Sotolongo escribió:
>
> SELECT
> unnest(string_to_array(pg_read_file('/usr/share/postgresql/'||current_setting
> ('server_version_num')::varchar(2)||'/tsearch_data/spanish.stop'),E'\n'))
> as stopwords;
(Esta query no funciona en el caso general: la ubicación del directorio
de instalación no es obtenible desde dentro de una sesión)
[ ... mirando el archivo ... ]
Uy, esta lista es desastrosa, tiene algunos typos Orribles [sic] como
vosostras
vosostros
y algunas palabras mal consideradas como
tenida
tenidas
que supongo pretenden ser conjugaciones del verbo tener, pero también
tienen otro significado, que a mi parecer las descalifican como
stopwords ...
Más generalmente me doy cuenta que este archivo no ha cambiado desde el
commit original en 2007 (140d4ebcb46e). También me doy cuenta que en
snowballstem.org (el proyecto upstream de nuestros stemmers) no hay nada
sobre stopwords, así que me imagino que las listas vinieron de algún
otro lado ... pero no encuentro dónde.
Existe esto
https://github.com/stopwords-iso/stopwords-es
que aparentemente viene de Snowball.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"The ability of users to misuse tools is, of course, legendary" (David Steele)
https://postgr.es/m/11b38a96-6ded-4668-b772-40f992132...@pgmasters.net
Re: Alto consumo de procesador
Fernando Siguenza escribió: > Amigos, su ayuda porfa tengo un servidor en debian con postgres ejecutando un > sistema en php, estaba funcionando bein pero desde el viernes veo que el > consumo del procesador esta altisimo y es por los procesos del postgres Ugh, suena a que tienes un cryptominero, algo como https://unit42.paloaltonetworks.com/pgminer-postgresql-cryptocurrency-mining-botnet/ Condolencias, -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ "La primera ley de las demostraciones en vivo es: no trate de usar el sistema. Escriba un guión que no toque nada para no causar daños." (Jakob Nielsen)
Re: no se pudo recibir datos del cliente: Conexión reinicializada por la máquina remota
mauricio pullabuestan escribió: > La configuración del Servidor maestro para almacenar los wals. > archive_mode = on > archive_command = 'cp %p /var/lib/postgresql/9.6/main/archive/%f' > > Es de este directorio donde borro los Wals. Ah, ok. Para eso te recomiendo usar pg_archivecleanup. > No creo tener transacciones preparadas olvidadas o transacciones que > nunca cerraron, con todo voy a revisar. Si no tienes archivos de toda la eternidad en pg_xlog, entonces no es un problema. Nota, eso sí, que el archive_command que estás usando tiene varias desventajas y podría causarte problemas a la larga. No se recomienda que manejes estas cosas tú mismo, porque es muy fácil hacerlas mal y terminar corrompiendo datos. Si esos WAL son para backups, te recomiendo usar Barman --> www.pgbarman.org Hay otras opciones para hacer backups. (Si no son para backups, entonces me pregunto para qué.) Saludos -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
Re: no se pudo recibir datos del cliente: Conexión reinicializada por la máquina remota
mauricio pullabuestan escribió: > Los archivos Wal se borran del servidor primario, por una tarea > programada mediante Cron que se ejecuta a 1:00, eliminando los > archivos del día anterior, ¿desde el directorio pg_xlog? Eso de borrar WALs de ahí es lo mismo que suicidar tu base de datos. Es un peligro y no deberías estarlo haciendo. Postgres borra esos archivos WAL por si mismo; si no lo está haciendo y necesitas este horrendo y peligroso hack, es que tienes algo mal configurado, como por ejemplo un slot de replicación inactivo, una transacción preparada olvidada, o una transacción que nunca se cerró. Verifica esas cosas y elimina ese cron jon. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
Re: búsqueda en cadena de texto como en google
Juan José Santamaría Flecha escribió: > On Wed, Dec 13, 2023 at 9:49 AM kernel wrote: > > > Tengo un campo varchar que contiene descripciones de libros, me gustaría > > poder buscar por diferentes palabras, pero pueden estar en orden > > distinto o solo contener algunas, no se si hay algo desarrollado o tengo > > que hacer varias busquedas > > Lo que quieres hacer suena a búsqueda Full Text: > > https://www.postgresql.org/docs/current/textsearch.html Usando websearch_to_tsquery() posiblemente. Puede ser necesario adornar con la extensión unaccent. Si tienes, por ejemplo, el titulo del libro en una columna y la descripción en una columna separada, puedes crear un índice que agrupa las palabras de ambas columnas, de manera que una búsqueda encuentre cuando las palabras aparezcan en cualquiera de los dos. También puedes darle "pesos" distintos a las palabras en cada columna (función setweight), de manera que si una palabra de la búsqueda aparece en el título, el resultado te muestre ese libro antes que un libro para el cual la palabra ocurre en la descripción. Generalmente es bueno saber en qué idioma están los textos, para que puedas decidir qué "stemming" usar. Mi impresión es que para el español esto funciona bien, pero no me ha tocado implementar aplicaciones de verdad usando esta funcionalidad. -- Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/ "After a quick R of TFM, all I can say is HOLY CR** THAT IS COOL! PostgreSQL was amazing when I first started using it at 7.2, and I'm continually astounded by learning new features and techniques made available by the continuing work of the development team." Berend Tober, http://archives.postgresql.org/pgsql-hackers/2007-08/msg01009.php
Re: Para las nuevas generaciones ¿Por qué aprender postgres?
Enrique Herrera Noya escribió: > me recuerdo haber implementado > > nodo1 y nodo2 postgres , y con GFS2 montamos el directorio de la BBDD desde > nodo 3 Esto suena a potencial mecanismo para corromper datos si algo llega a salir mal, porque el bloqueo entre procesos no va a funcionar si el directorio de datos está en una máquina distinta, y eso podría causar que múltiples instancias en ejecución modifiquen los mismos datos simultáneamente, creando inconsistencias. Me tocó atender algún caso así con directorios de datos montados vía NFS, hace muchos años atrás. > y como alternativa a RAC, me recuerdo postgresql XL Ese proyecto murió hace tiempo. La última versión publicada fue en 2019, basado en Postgres 10. -- Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/ "Learn about compilers. Then everything looks like either a compiler or a database, and now you have two problems but one of them is fun." https://twitter.com/thingskatedid/status/1456027786158776329
Re: Error "public.powa_take_snapshot()" en el log de PostgreSQL
Pablo Delgado escribió: > Tengo el siguiente error en mi log de PostgreSQL 12 y no llego a entender > como solucionarlo: > > 2023-10-07 16:03:06 UTC:LOG: POWA connected to database powa > 2023-10-07 16:03:06 UTC:ERROR: query returned more than one row > 2023-10-07 16:03:06 UTC:HINT: Make sure the query returns a single row, or > use LIMIT 1. > 2023-10-07 16:03:06 UTC:CONTEXT: PL/pgSQL function > powa_take_snapshot(integer) line 31 at SQL statement > SQL statement "SELECT public.powa_take_snapshot()" > 2023-10-07 16:03:06 UTC:LOG: background worker "powa" (PID 34049) exited > with exit code 1 Hola, eso es un bug en un módulo externo llamado POWA. Podrías intentar desactivarlo, pero si te interesa continuar usando POWA, fíjate si los desarrolladores han publicado una versión más reciente que contenga una corrección a algún problema relacionado. Aparentemente, lo que hay que hacer es quitar "powa" de la línea shared_preload_libraries en postgresql.conf (o busca en `select * from pg_settings` si ese parámetro viene desde algún otro archivo). Luego reinicia el servidor. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ Bob [Floyd] used to say that he was planning to get a Ph.D. by the "green stamp method," namely by saving envelopes addressed to him as 'Dr. Floyd'. After collecting 500 such letters, he mused, a university somewhere in Arizona would probably grant him a degree. (Don Knuth)
Re: Funciones Temporales en Postgres
Jose Mercedes Venegas Acevedo escribió: > Buen dia a todos > > Estoy intentando armar una funcion en postgres que utilizara parámetros y > tablas distintas dependiendo del usuario que se conecta por ese motivo se > me ocurrió que tal vez podria escribir un script que utilice algo asi como > funciones temporales create function pg_temp.funcion() ...; select pg_temp.funcion() ; Al desconectar, se borra. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ Tom: There seems to be something broken here. Teodor: I'm in sackcloth and ashes... Fixed. http://postgr.es/m/482d1632.8010...@sigaev.ru
Re: Optimizar Update
mauricio pullabuestan escribió: > SET work_mem = '500MB'; > TRUNCATE item_bodega_pedidos_spp; > COPY item_bodega_pedidos_spp FROM '/home/pasa_vfp_pg/bodega_migra.csv' > DELIMITER ',' CSV HEADER; Asegúrate de hacer un ANALYZE después de insertar los datos en esta tabla. -- Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/ "It takes less than 2 seconds to get to 78% complete; that's a good sign. A few seconds later it's at 90%, but it seems to have stuck there. Did somebody make percentages logarithmic while I wasn't looking?" http://smylers.hates-software.com/2005/09/08/1995c749.html
Re: Optimizar Update
mauricio pullabuestan escribió: > CREATE TABLE bodegas /*la tabla es mucho más ancha*/ > ( > > bodega character varying(3) NOT NULL, > item character varying(15) NOT NULL, > buffer numeric(12,3) DEFAULT 0, > pedidos_clientes numeric(12,3) DEFAULT 0, > comprometido_pedido numeric(10,3) DEFAULT 0, > CONSTRAINT pk_bodegas PRIMARY KEY (bodega, item), > CONSTRAINT fk_bodegas_id_bodegas FOREIGN KEY (bodega) > REFERENCES id_bodegas (bodega) MATCH FULL > ON UPDATE NO ACTION ON DELETE NO ACTION, > CONSTRAINT fk_bodegas_item FOREIGN KEY (item) > REFERENCES items (item) MATCH SIMPLE > ON UPDATE NO ACTION ON DELETE NO ACTION > ) ¿tienes una llave foránea que dice que la bodega existe en la misma tabla bodegas? ¿es decir, la tabla se autoreferencia? Suena medio estúpido esto. ¿Qué sentido tiene? -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ "People get annoyed when you try to debug them." (Larry Wall)
Re: alguna base de datos abierta
Enrique Herrera Noya escribió: > me tope con un tema practico , como son varios teras desde el cual > debo seleccionar la muestra, me demorare mas tiempo que el plazo de > entrega de la maqueta, entonces, para armar la maqueta se me ocurrió > que podría utilizar una bbdd abierta de algunos gigas, para utilizarla > como insumo para mostrar los pasos que realizare con la bbdd a > analizar. Podrías crear una muestra aleatoria de la base de datos existente, usando "SELECT FROM .. TABLESAMPLE" que hace una muestra aleatoria en forma eficiente. Con eso puedes extraer el tamaño que te convenga, lo pones en una tabla aparte "de muestra". Creo que eso sería más sencillo que tratar de encontrar una base de datos de ejemplo que se ajuste a lo que necesitas hacer. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
Re: Tabla TOAST muy grande
Diego Ayala escribió: > buen dia Francisco, si, tienes razon, mi calculo esta mal, en realidad son > 1.2MB por cada columna JSON 1,2MB x 545800=654.960MB que son 69 GB solo > para esa columna, y el total de la tabla es 72GB, que corresponden al resto > de las columnas. > Usando esta función para estimar el tamaño total de esa columna > > select pg_size_pretty(sum(pg_column_size(evento.datos))) FROM pliego.evento Eso suena más razonable. Comprimir un JSON gigante a ~10% del tamaño original podría ser creíble si suponemos que hay muchísima redundancia en los datos. Un JSON de 1.2MB seguramente debe ser un absoluto desastre de diseño, así que una redundancia tan alta podría ser alcanzable. El otro número no tenía ningún sentido. > Estoy evaluando eliminar registros anteriores a 1 año para liberar espacio Me imagino que cuando dices "eliminar" quieres decir "mover los datos antiguos a otra tabla con información histórica". -- Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/ "The Gord often wonders why people threaten never to come back after they've been told never to return" (www.actsofgord.com)
Re: Tabla TOAST muy grande
Diego Ayala escribió: > si, es en la columna tipo json donde tengo el dato mayor, ¿qué tan grandes son esos objetos json? Para llegar a 72 GB con 545800 objetos, cada uno de ellos tendría que ser de 141644 bytes. Eso parece un poco excesivo. ¿No será que hay espacio desperdiciado en esa tabla? Otra cosa: si estás haciendo respaldos solamente con pg_dump con una BD de ese tamaño, podrías estar poniéndote en riesgo. Te aconsejaría hacer respaldos con pgBarman o pgBackrest. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ "Los trabajadores menos efectivos son sistematicamente llevados al lugar donde pueden hacer el menor daño posible: gerencia." (El principio Dilbert)
Re: Baja performance en inserts masivos con bytea
Guillermo E. Villanueva escribió: > Cómo los datos originales tenían una columna lo (large object) los tengo > que pasar a bytea, para eso utilizo la función: [...] > El problema es que *demora muchísimo!!!* para hacer la primera vuelta de > ciclo, es decir los primeros 1 registros demoró poco mas de 1 hora y la > tabla tiene 2.5 millones de registros :-( ¿de qué tamaño es cada objeto? Es posible que sea problema de compresión. Prueba con ALTER TABLE tca_bytea ALTER COLUMN tca_texto SET STORAGE EXTERNAL; https://www.postgresql.org/docs/9.2/sql-altertable.html para evitar que intente comprimir los valores durante la inserción. Eso podría hacerlo mucho más rápido. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
Re: error prev-link
kernel escribió: > hola, > > > Me he encontrado con este error en el servidor de respaldo, esta > constantemente dando ele problema y esta desentronizado Lo sacaron del trono, ¿eh? Ojalá no lo hayan pasado por la guillotina también. > 2023-06-01 00:00:43.748 CEST [1273] LOG: se ha restaurado el archivo > «00010094008F» desde el área de archivado > 2023-06-01 00:00:43.939 CEST [1273] LOG: registro con prev-link 1803FF/CC > incorrecto en 94/8F141388 ¿qué versión de postgres es esta? Es posible que necesites re-clonar el standby, y actualizar tus servidores para conseguir esta corrección: Author: Alvaro Herrera Branch: master Release: REL_15_BR [ff9f111bc] 2021-09-29 11:21:51 -0300 Branch: REL_14_STABLE Release: REL_14_1 [64a8687a6] 2021-09-29 11:41:01 -0300 Branch: REL_13_STABLE Release: REL_13_5 [1d97d3d08] 2021-09-29 11:21:51 -0300 Branch: REL_12_STABLE Release: REL_12_9 [1df0a914d] 2021-09-29 11:21:51 -0300 Branch: REL_11_STABLE Release: REL_11_14 [cfedb279a] 2021-09-29 11:21:51 -0300 Branch: REL_10_STABLE Release: REL_10_19 [d9fe2cc7d] 2021-09-29 11:21:51 -0300 Branch: REL9_6_STABLE Release: REL9_6_24 [148c6ee3b] 2021-09-29 11:21:51 -0300 Fix WAL replay in presence of an incomplete record Physical replication always ships WAL segment files to replicas once they are complete. This is a problem if one WAL record is split across a segment boundary and the primary server crashes before writing down the segment with the next portion of the WAL record: WAL writing after crash recovery would happily resume at the point where the broken record started, overwriting that record ... but any standby or backup may have already received a copy of that segment, and they are not rewinding. This causes standbys to stop following the primary after the latter crashes: LOG: invalid contrecord length 7262 at A8/D9FFFBC8 because the standby is still trying to read the continuation record (contrecord) for the original long WAL record, but it is not there and it will never be. A workaround is to stop the replica, delete the WAL file, and restart it -- at which point a fresh copy is brought over from the primary. But that's pretty labor intensive, and I bet many users would just give up and re-clone the standby instead. A fix for this problem was already attempted in commit 515e3d84a0b5, but it only addressed the case for the scenario of WAL archiving, so streaming replication would still be a problem (as well as other things such as taking a filesystem-level backup while the server is down after having crashed), and it had performance scalability problems too; so it had to be reverted. This commit fixes the problem using an approach suggested by Andres Freund, whereby the initial portion(s) of the split-up WAL record are kept, and a special type of WAL record is written where the contrecord was lost, so that WAL replay in the replica knows to skip the broken parts. With this approach, we can continue to stream/archive segment files as soon as they are complete, and replay of the broken records will proceed across the crash point without a hitch. Because a new type of WAL record is added, users should be careful to upgrade standbys first, primaries later. Otherwise they risk the standby being unable to start if the primary happens to write such a record. A new TAP test that exercises this is added, but the portability of it is yet to be seen. This has been wrong since the introduction of physical replication, so backpatch all the way back. In stable branches, keep the new XLogReaderState members at the end of the struct, to avoid an ABI break. Author: Álvaro Herrera Reviewed-by: Kyotaro Horiguchi Reviewed-by: Nathan Bossart Discussion: https://postgr.es/m/202108232252.dh7uxf6oxwcy@alvherre.pgsql -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
Re: Unsuscribe me
Isma Santacruz Vera escribió: > Hello > Could you please unsubscribe me? Hecho. -- Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/ "How amazing is that? I call it a night and come back to find that a bug has been identified and patched while I sleep."(Robert Davidson) http://archives.postgresql.org/pgsql-sql/2006-03/msg00378.php
Re: Manejo de privilegios en database y esquemas
xav...@datolibre.com escribió: > Estimados amigos. Hola! > Lo que quiero es: > > * "chief" siempre tenga acceso (lectura y escritura) a todas las tablas > que se creen en los esquemas operator0, operator1... y a su vez que pueda > dar privilegios SELECT a otros usuarios. Después del CREATE SCHEMA, dale [algo parecido a] un: ALTER DEFAULT PRIVILEGES ON SCHEMA operator0 GRANT ALL PRIVILEGES ON TABLES TO chief; > * "operator0" ya tiene acceso (lectura y escritura) sobre todas las > tablas > en el esquema operator0, pero quiero que sea capáz de otorgar privilegios > SELECT a otros usuarios. Hmm, creo que debería ser ALTER DEFAULT PRIVILEGES IN SCHEMA operator0 GRANT SELECT ON TABLES WITH GRANT OPTION; -- Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/ "La grandeza es una experiencia transitoria. Nunca es consistente. Depende en gran parte de la imaginación humana creadora de mitos" (Irulan)
Re: Pg 9.6 va ganandole a pg13 en performance test, que esta mal?
Carlos T. Groero Carmona escribió: > Logre poner los tiempos de respuesta de 9.6 y 13 juntos en NewRelic y > encontre que todo funciono un poco mas lento pero el mas critico fue > postgres con un 27%, aproximadamente 90ms mas lento. Es difícil sacar conclusiones de una medición tan gruesa (o al menos tan inespecífica), pero yo me estaría preguntando si no hay un problema de latencia de red entre máquinas que sea distinto entre las instancias que levantas con 9.6 vs. las instancias que levantas con 13. Entiendo que dijiste que todo es automatizado, lo cual significa que las topologías de red deberían ser equivalentes y por lo tanto tener las mismas latencias. Pero surge la pregunta si las instancias 9.6 son históricas o fueron recién creadas, como las 13. Por otra parte, es muy difícil de creer que Postgres se haya hecho "90 ms más lento" en forma pareja en todas las queries. Pero si me dijeras que hay unas cuantas consultas con CTE (cláusulas WITH) que son 1000x más lentas que antes y que eso hace que el tiempo de ejecución promedio sea mayor, eso es totalmente creíble y podría tener la solución sencilla de agregar el modificador MATERIALIZED a la CTE. Estos artículos son relevantes: https://paquier.xyz/postgresql-2/postgres-12-with-materialize/ https://www.depesz.com/2019/02/19/waiting-for-postgresql-12-allow-user-control-of-cte-materialization-and-change-the-default-behavior/ -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ "La espina, desde que nace, ya pincha" (Proverbio africano)
Re: Pg 9.6 va ganandole a pg13 en performance test, que esta mal?
Carlos T. Groero Carmona escribió: > Hola a todos, > > Estoy migrando de 9.6 a 13 y parte del proceso migratorio es hacer los test > de performance atravez de la aplicacion y las funcionalidades mas > importantes del systema. > > Se nota una degradacion de un 16% en el throughput y un 25% en el tiempo de > respuesta del systema cuando usamos pg13. ¿es una query específica que es más lenta, o es que todo el sistema está más lento? -- Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/
Re: Optimización de consulta
Guillermo E. Villanueva escribió: > *product_.status = 1 and and product_.qty > 0* > > provocan seq. scan y el mayor costo y tiempo de mi consulta > la tabla product_ tiene 69300 filas > status = 1 son 49500 > qty > 0 son 65700 > > el explain me dice: > -> Parallel Seq Scan on product_ (cost=0.00..19483.64 rows=19580 > width=30) (actual time=0.032..39.454 rows=15674 loops=3) > Filter: ((qty > '0'::numeric) AND (status = 1)) > Rows Removed by Filter: 7454 > > Si creo índices individuales o combinando ambas columnas no mejora, sigue > haciendo seq. scan La tabla es muy pequeña y las cláusulas son poco selectivas, así que el seqscan ya es la mejor estrategia. Pero prueba haciendo "set enable_seqscan to 0" a ver si usando un índice anda más rápido (dudoso). Si la tabla fuera muy grande y la fracción de registros que tienen status=1 AND qty>0 es suficientemente pequeña, podría resultar en un plan distinto/mejor. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ "Oh, great altar of passive entertainment, bestow upon me thy discordant images at such speed as to render linear thought impossible" (Calvin a la TV)
Re: disponibilidad de la función sha512
kernel escribió:
> Hola,
>
> Creo que la función sha512 esta disponible a partir de la versión 10.20
>
> ¿hay alguna posibilidad de disponer de la función en versiones anteriores?,
> ¿alguna extensión?, ¿alguna función que pueda instalar?
Hola, en pgcrypto está la función digest que recibe como segundo
argumento el nombre del algoritmo:
$ select digest('hola hola', 'sha512');
digest
\x9f1857e99043f9e97b502c900fb8c84ece9cc7f942061e277c6f98bd7f736f011ad1b6c94659a3d631179bfdd8851f2b5ee9d8678404d2f40708f747d1f19037
(1 fila)
Mismo resultado obtienes en 14 (digo, para verificar):
$ select sha512('hola hola');
sha512
\x9f1857e99043f9e97b502c900fb8c84ece9cc7f942061e277c6f98bd7f736f011ad1b6c94659a3d631179bfdd8851f2b5ee9d8678404d2f40708f747d1f19037
(1 fila)
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"No hay hombre que no aspire a la plenitud, es decir,
la suma de experiencias de que un hombre es capaz"
Re: Infierno de las comillas dobles en plpgsql
Francisco Olarte escribió: > Tu problema parece el tipico del quote del quote del quote... que es > un follon pero se suele resolver razonablemente usando distinatas > comillas, de las que en sql hay infinitas usando $x$. Ahora no tengo > acceso ha nada para probarlo pero yo probaria algo asi. Buenísima la explicación. Una pequeña aclaración ... las "comillas de dólar" no son parte del lenguaje SQL, sino que son una extensión de PostgreSQL, las inventó como concepto Tom Lane acá: https://www.postgresql.org/message-id/flat/10291.1063374003%40sss.pgh.pa.us#5c10796bfe4e4632f140b4ef7e88799c Y finalmente implementado por Andrew Dunstan acá: https://www.postgresql.org/message-id/40225C1B.6020606%40dunslane.net https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=58e705320e0c9e691a3fd2bd544f375ee0ca23d6 El nombre "dollar quoting" se le ocurrió a Hannu Krosing: https://www.postgresql.org/message-id/flat/1063572973.2412.16.camel%40fuji.krosing.net#eaccf882017da65bffbaa32a2137ed6a -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ "I think my standards have lowered enough that now I think 'good design' is when the page doesn't irritate the living f*ck out of me." (JWZ)
Re: pg_restore ERROR: unexpected message type 0x58 during COPY from stdin
Diego Ayala escribió: > Gracias por la respuesta, espacio en disco no creo, por que tiene > suficiente, estoy analizando los logs para ver donde se esta dando el > problema. A veces los equipos de red intermedios (routers, switches) se fastidian cuando llevas una conexión con una transmisión muy grande. Es muy probable que sea el caso acá, te recomiendo revisar la red con mucho cuidado. Si no tienes ninguna otra opción para investigar, trata de conectar el equipo que ejecuta el restore directo al servidor de BD; o bien ejecuta el restore en el mismo servidor. O incluso un detector de intrusiones o mecanismo de seguridad a nivel del kernel. Creo que una vez vi ese caso, con AppArmor me parece. -- Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/ "I must say, I am absolutely impressed with what pgsql's implementation of VALUES allows me to do. It's kind of ridiculous how much "work" goes away in my code. Too bad I can't do this at work (Oracle 8/9)." (Tom Allison) http://archives.postgresql.org/pgsql-general/2007-06/msg00016.php
Re: Error al usar la herramienta osm2pgrouting
Carlos Eduardo Gutierrez Uruenna escribió:
> Buen día para todos y todas.
>
> En esta oportunidad quisiera acudir a ustedes dado que al usar la
> herramienta osm2pgrouting cuyo propósito está orientado a importar la capa
> de vías/carreteras de OSM para cualquier país; me devuelve unos errores
> como los siguientes:
>
>
>- 2021-11-26 00:12:47.525 -05 [13436] FATAL: lo siento, ya tenemos
>demasiados clientes
¿Qué versión de Postgres estás usando?
"ya tenemos demasiados clientes" significa que tienes el máximo de
conexiones activas. Puedes aumentar max_connections en postgresql.conf,
pero quizás necesites revisar por qué algunas conexiones no se estén
cerrando.
>- 2021-11-26 00:16:02.625 -05 [20536] LOG: no se pudo recibir datos del
>cliente: unrecognized winsock error 10054
Hmm, ni idea de qué va esto. 10054 es un código de error de Winsock
("Connection reset by peer" o WSACONNRESET), pero no entiendo por qué no
se entrega un mensaje de error más legible. Quizás
win32_socket_strerror() necesita adaptarse, o el código que lo está
invocando, aunque se supone que está específicamente para manejar estos
casos.
--
Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/
"Tiene valor aquel que admite que es un cobarde" (Fernandel)
Re: Problema con pg_hba.conf tras cambio inesperado de IP
Yessica Brinkmann escribió: > Bien, entonces, fui a modificar mi archivo pg_hba.conf para que reflejara > la nueva IP que nosé porqué cambió, y poder seguir comunicándome entre las > dos máquinas virutales, pero resulta que al cambiar mi archivo pg_hba.conf, > igual no me funciona la conexión. ¿Hiciste "reload" en el servidor después de cambiar el archivo? Los cambios en los archivos de configuración no toman efecto hasta que lo hayas hecho. Posibles alternativas son ejecutar "pg_ctl reload", o "SELECT pg_reload_conf()", o usar "systemctl postgresql reload", o enviar una señal SIGHUP al proceso servidor principal (postmaster). -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
Re: Hola tengo una duda de performance.
Horacio Miranda escribió: > Estoy revisando y no encuentro una respuesta clara sobre el tipo de > texto TEXT para los siguientes casos. > > Tengo entendido que el varchar en postgresql soporta 1G segun lo que > estoy leyendo lo que no me queda claro es la penalización de > performance cuando tengo TEXT y hago cast entre otras columnas de tipo > varchar. La representación física de ambos es la misma. La única diferencia es que VARCHAR tiene que contar caracteres para saber en qué punto está el corte; el único costo de rendimiento es hacer eso cuando es necesario. > En Oracle los CLOB son un puntero a otra estructura que puede existir > incluso en otro tablespace. Suena como a un "large object", que también es un puntero (OID) a datos que están almacenados en pg_largeobject. Ahora, si haces UPDATE tabla2 SET algún_varchar = algún_text_que_está_en_otra_tabla entonces vas a tener dos copias del dato, una en cada tabla. > no estoy seguro sobre TEXT, es posible si alguien tiene mas > información sobre este tema sería genial saberlo. Voy a seguir > leyendo. Hmm, no se me ocurre qué recomendarte leer sobre este tema. La documentación de TOAST explica en qué casos se trata de hacer compresión; si tus datos no son compresibles porque ya están comprimidos (JPG, PDF, o un base64 de una imagen) entonces te conviene configurar la columna para que no intente comprimir, porque va a perder mucho tiempo. Si es texto natural, la compresión gana rendimiento por el hecho de disminuir I/O. > Estoy pensando para bases de datos grandes el performance como se > mueve postgresql con CAST y TEXT. El cast es una transformación sólo de metadatos, así que el costo en rendimiento debería ser pequeño. Ahora, si necesitas extraer substrings de textos largos, considera guardarlos sin compresión, porque el acceso es más eficiente. -- Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/
Re: que considerar en un update de versión?
Jaime Casanova escribió: > Álvaro y tu ya cubrieron todos los puntos, pero como no me quería quedar > fuera de la conversación agregaré que esto es porque Centos 8 ya no > existe fue reemplazado por Centos Stream. > > Centos Stream no es una versión para producción. Tampoco es una versión > en el sentido normal de la palabra, es una distribución en continuo cambio > (por eso el nombre stream) en el que se van a probar paquetes que luego > pasarán a los nuevos releases de RHEL. Ahora, Enrique mencionó que va a migrar a Almalinux, que es precisamente el clon de CentOS que pretende continuar lo que abandonará Redhat (y que está apoyado por un buen puñado de otras empresas con interés en la continuidad). Lo único que me preocupa de ese plan es que Almalinux no está en la lista de distribuciones soportadas por los repos de yum.postgresql.org. De todas formas, Almalinux tiene sus propios paquetes de Postgres. Saludos -- Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/
Re: que considerar en un update de versión?
Hola Enrique, Enrique Herrera Noya escribió: > en mi nuevo trabajo estoy llevando a cabo la migración de los servidores > desde Centos 7.9 a Centos 8.4. > > ya estoy por realizar la actualización en las maquinas con postgresql > > estas maquinas tienen postgresql 9.2.24 y viendo cual tiene centos 8.4, > tiene la versión 9.6.22 (ademas de las versiones 10,12 y 13) Recuerda que existen repositorios Yum ofrecidos por el proyecto PostgreSQL que tienen (casi) todas las versiones de Postgres para muchas versiones de CentOS. Tienes donde escoger. https://yum.postgresql.org > las BBDD son accedidas con sentencias SQL estandar, y no tienen ninguna > definición compleja a nivel de tablas > > mi duda es si la actualización a 9.6.22 seria "transparente" y sin impacto? Puede que sí sea "transparente", pero como es un salto grande, yo no lo haría sin antes verificar. Es decir, haz un upgrade de prueba en un servidor experimental, le instalas la aplicación, y verifica el funcionamiento de toda la funcionalidad, o al menos las partes más importantes. Si algo falla, puedes corregirlo antes de hacer el upgrade de verdad. Sospecho que lo primero que vas a notar es que varias cosas serán mucho más rápidas en Postgres 13 que en 9.2. > (mi idea es primero llevarla a 9.6.22 y luego a la versión 13) Eso no es necesario ... con pg_upgrade puedes hacer el salto de una sola vez, y te ahorras trabajo. > Nota: posterior a eso la idea es realizar el cambio desde Centos hacia > Almalinux Hmm, desconozco Almalinux. No sé si hay paquetes. Saludos -- Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/
Re: upgrade 9.2 a 13
Guillermo E. Villanueva escribió: > Buenas! ¿Es posible utilizar la herramienta pg_upgrade en un solo paso para > pasar de un opensuse 12 con postgresql 9.2 a un centos 8 con postgresql 13? > cada uno en VM diferentes dentro de la misma red local. Puedes usar pg_upgrade para ir de 9.2 a 13 en un solo paso, pero necesitarás un paso separado para mover el directorio de datos resultante de una VM a otra. -- Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/ "Uno puede defenderse de los ataques; contra los elogios se esta indefenso"
Re: Consulta migracion
Ivan Perales M. escribió: > Y que pasa si haces un pg_dump (en modo insert o copy) y luego importas > con un psql, es recomendable? El formato de texto es menos flexible, pero si lo único que te importa es restaurarlo una única vez, funciona bien (de hecho, es exactamente lo mismo que tomar un pg_dump -Fc y darle inmediatamente un pg_restore a salida de texto). La ventaja de los formatos "custom" y "directory" es que tienes mucha flexibilidad con lo que puedes hacer con ellos después. El modo insert no se recomienda a menos que quieras pasar los datos a un motor distinto. Los INSERT son SQL estándar, en cambio el COPY no lo es. -- Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/ "Linux transformó mi computadora, de una `máquina para hacer cosas', en un aparato realmente entretenido, sobre el cual cada día aprendo algo nuevo" (Jaime Salinas)
Re: Consulta migracion
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
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: Réplicacion de PostgreSQL a mysql no trigger
Hellmuth Vargas escribió: > Hola lista > > Tiempo sin escribir! resulta que tenemos que enviar los datos de unas > tablas de PostgreSQL a mysql de forma permanente (como réplicacion lógica > pero al motor mysql) la versión de PostgreSQL es 11 aunque se podría subir > a 13, ya he investigando pero de las opciones free quizas symmetricDS es de > las más conocidas pero hace esto con trigger (hasta donde pude ver) y la > verdad esperaría que pudiera hacerse con la réplicacion (lógica) pues para > no afectar desempeño de las operaciones DML en PostgreSQL, que alternativas > ahí para esto. Hola Hellmuth, quizás una opción podría ser el wal2json, y hacer un programa pequeño que consuma el JSON que emita para alimentar el MySQL. Saludos -- Álvaro Herrera Valdivia, Chile "But static content is just dynamic content that isn't moving!" http://smylers.hates-software.com/2007/08/15/fe244d0c.html
Re: Attach tabla con datos a partición nativa
Hellmuth Vargas escribió: > bash-4.1$ du --max-depth=1 > 16 ./log > 16 ./pg_logical > 4 ./pg_commit_ts > 1616756 ./base > 28 ./pg_multixact > 4 ./pg_serial > 12 ./pg_subtrans > 12 ./pg_notify > 4 ./pg_tblspc > 1900552 ./pg_wal Una cosa que no me había dado cuenta es que estás midiendo el tráfico de WAL según la cantidad de espacio que ocupa pg_wal. Eso no es muy certero, o mejor dicho es fácil equivocarse, porque si bien estás ejecutando checkpoints manualmente en tu prueba, igual podría pasar que el sistema haga un checkpoint a medio camino. Es más seguro obtener un LSN con "SELECT pg_current_wal_insert_lsn()" antes y después, y restar los valores. Eso te da la cantidad en bytes de WAL que se genera durante el experimento, con total seguridad. Saludos -- Álvaro Herrera39°49'30"S 73°17'W "No tengo por qué estar de acuerdo con lo que pienso" (Carlos Caszeli)
Re: Attach tabla con datos a partición nativa
Hellmuth Vargas escribió: > Hola Avaro > > Hice el correspondiente laboratorio en una instancia dedicada de PostgreSQL > 11.11, uno con una tabla "padre" con primariy key definido y otra con tabla > "padre" sin el primary key, aqui los resultados Eh, me expresé mal (error de cafeína insuficiente). Lo que yo quería sugerir es que en la *partición* crearas el índice antes de hacer el ATTACH. Eso lo puedes hacer con CONCURRENTLY. Al momento de hacer ATTACH, el sistema va a detectar que el índice que necesita ya existe y entonces no necesita crearlo. Eso sí, tiene que ser un índice con exactamente las mismas propiedades que el que está en la tabla padre. -- Álvaro Herrera39°49'30"S 73°17'W
Re: Attach tabla con datos a partición nativa
Hellmuth Vargas escribió: > Hola Álvaro > > El dom., 2 de mayo de 2021 10:00 p. m., Alvaro Herrera < > alvhe...@alvh.no-ip.org> escribió: > > > Hellmuth Vargas escribió: > > > > > La instrucciones que ejecute básicamente fueron: > > > > > > CREATE TABLE llamadas ( > > >campos > > > ) PARTITION BY RANGE (fecha); > > > > ¿hay índice o PK en estos campos? > > Si señor, PK > > CREATE TABLE llamadas ( > id bigserial not null, > fecha timestamp, > constraint pk_llamadas primary key (id, fecha) > ) PARTITION BY RANGE (fecha); Prueba creando el índice en las tablas antes de hacer el attach. (No recuerdo si basta con CREATE UNIQUE INDEX o es necesario ADD PRIMARY KEY). -- Álvaro Herrera39°49'30"S 73°17'W "En las profundidades de nuestro inconsciente hay una obsesiva necesidad de un universo lógico y coherente. Pero el universo real se halla siempre un paso más allá de la lógica" (Irulan)
Re: Attach tabla con datos a partición nativa
Hellmuth Vargas escribió: > La instrucciones que ejecute básicamente fueron: > > CREATE TABLE llamadas ( >campos > ) PARTITION BY RANGE (fecha); ¿hay índice o PK en estos campos? ¿qué versión de Postgres? -- Álvaro Herrera Valdivia, Chile "I must say, I am absolutely impressed with what pgsql's implementation of VALUES allows me to do. It's kind of ridiculous how much "work" goes away in my code. Too bad I can't do this at work (Oracle 8/9)." (Tom Allison) http://archives.postgresql.org/pgsql-general/2007-06/msg00016.php
Re: ERROR: las tablas declaradas WITH OIDS no está soportado
Micky Khan escribió: > Buenos Dias. Hola Micky, > Estaba pasando mi base de datos de la version 9.X a la 13.2 y me > salieron estos "errores".. a que se debe ??? > > Restoring started > Creating database sigtext... > Done > Executing script G:\KJKJKJK.sql... > ERROR: las tablas declaradas WITH OIDS no está soportado > ERROR: las tablas declaradas WITH OIDS no está soportado Esto puede ser fácil: edita el .sql y borra el WITH OIDS de todas partes. O puede ser difícil: si alguna de tus tablas depende de que haya OID, entonces algo va a dejar de funcionar cuando hagas eso. No es muy probable que eso pase, pero depende de qué tan astuto fue tu yo-anterior. > Hay alguna forma en todo caso de hacer un backup y restaurarlo sin > problemas o como se puede corregir. Una opción es usar el pg_dump de 13.2 para conectarte a la base de datos y extraer el backup. -- Álvaro Herrera39°49'30"S 73°17'W
Re: Particionar o no Particonar
Edwin De La Cruz escribió: > Ahora, me veo en la necesidad de instalar esa aplicación para un > cliente cuya infraestructura dispone de un servidor con PostgreSQL 10. > Mi aplicación la tengo bajo PostgreSQL 12. > El cliente no puede actualizar versión. Estoy de acuerdo con lo que dijo Iván Perales. La licencia de Postgres es muy barata como para intentar ahorrar en la cantidad de servidores con PostgreSQL que puedas tener. En última instancia (es decir si tu cliente no es capaz ni de comprar otro servidor), puedes instalar ambas versiones de Postgres en el mismo servidor, en puertos distintos. Tratar de modificar toda tu aplicación para que funcione con una versión de Postgres prácticamente obsoleta (porque eso es lo que es, en 2021, Postgres 10) te va a traer una gran cantidad de dolores de cabeza, y ganancias mínimas. Lo más probable es que la funcionalidad X resulte lenta, y el cliente va a querer que la hagas más rápida. -- Álvaro Herrera39°49'30"S 73°17'W "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 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 borrar registros en cascada
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: Problema con pgbench y versiones de Postgresql.
Yessica Brinkmann escribió: >Muchas gracias por la respuesta. Justamente estoy trabajando con >máquinas virtuales. Y en realidad necesito ejecutar el pgbench en la >máquina virtual en la que estoy trabajando con la versión 8.3.23, ya >que es justamente para trabajar con mi tesis. Y la versión 9.6 creo que >se instaló por defecto al usar el comando mencionado para instalar. pgbench es una aplicación cliente, que puede comunicarse a través de la red con el servidor. Mi sugerencia es que no necesitas ejecutar pgbench en la misma máquina. -- Álvaro Herrera Valdivia, Chile
Re: Problema con pgbench y versiones de Postgresql.
Yessica Brinkmann escribió: > Buenos días. > Estoy usando Postgresql 8.3.23 sobre Debian 9.x. > Aclaro que estoy obligada a usar dicha versión de Postgresql debido a que > estoy realizando una tesis de la universidad. Por este motivo me sería > imposible cambiar de versión de la base de datos. > Bien, yo estoy tratando de usar el pgbench para evaluar el rendimiento de > una base de datos Postgresql. Hola, te sugiero usar dos máquinas distintas: en una se ejecuta el servidor, con todo el software que necesitas para la versión 8.3, y en otra se ejecuta el programa pgbench, con la versión que sea (no sé por qué escogiste 9.6; mi sugerencia es usar lo que sea que Debian instale por defecto). Así no te vas a complicar tanto con el asunto de las dependencias incompatibles entre paquetes. (Las máquinas podrían ser virtuales.) Saludos -- Álvaro Herrera39°49'30"S 73°17'W "El hombre nunca sabe de lo que es capaz hasta que lo intenta" (C. Dickens)
Re: Limite en intentos fallidos de login.
Martín Marqués escribió: > Interesante. No habia pensado en el uso de fail2ban. > > La desventaja de este metodo es que bloque el IP, por lo que, si son > varios usuarios que se authentican desde el mismo IP quedarían todos > bloqueados y no solo el que super el limite de intentos. No necesariamente. Fail2ban es parametrizable y tú puedes configurar qué acción ejecutar al ocurrir un ban. No lo he intentado pero debería ser posible hacer "psql -c 'alter user foobar ...'" o algo por el estilo. -- Álvaro Herrera Valdivia, Chile "La libertad es como el dinero; el que no la sabe emplear la pierde" (Alvarez)
Re: porque no emplea indice para algunas funciones agregadas (max,min)
Hellmuth Vargas escribió: > Hola Alvaro > > Mil gracias por la respuesta, pues valdría la pena apoyar el parche porque > sera una forma rápida de obtener algunas funciones agregadas (máximos, > mínimos) agrupados por "categorias" directamente desde un indice asociado > el cual si esta ordenado debe debería resolverlo rápidamente este tipo > de consultas son muy comunes... que opinan? Hola, estaba mirando el archivo de la lista por otras razones y vi este mensaje. Pensé que sería buena idea comentar que el parche que mencionaba en ese momento fue incluido en Postgres 13, por si aún no te has subido de versión, para que veas qué tal te funciona. Saludos PD: http://postgr.es/m/flat/can3qy4pfnu0pfhbgf8nanjzc5vddzjoyepd7cmuprbgwb3_...@mail.gmail.com por si no tienes los mails de ese tiempo -- Álvaro Herrera39°49'30"S 73°17'W "Saca el libro que tu religión considere como el indicado para encontrar la oración que traiga paz a tu alma. Luego rebootea el computador y ve si funciona" (Carlos Duclós)
Re: Consulta sobre Json o jsonb
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 lenta
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 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: Tabla con particionado y alta cantidad de UPDATE
Edwin De La Cruz escribió:
> Voy a explicar de forma ańaloga como funciona el ingreso de datos,
> pensemos en un sistema de alarma:
> 1) Cuando se abre una puerta se genera un evento de "alarma".
> 2) Ahora cuando se cierra la puerta se genera un evento de
> "Restauración de alarma", lo cual cancela ("ACTUALIZA EL ESTADO") del
> evento anterior.
Hm, yo apoyo lo que dice Jaime, a saber, que el diseño no es el adecuado.
Sugiero pasar un par de horas pensando en un diseño que te permita
implementar tus necesidades sin requerir estas operaciones de doble
efecto.
Hay modificaciones al motor Postgres que todavía están pendientes para
que tablas particionadas tengan rendimiento parecido a tablas normales.
Algunas están en pg11, otras en pg12 y 13, pero todavía hay propuestas
en pg14. Lo que trato de argumentar es que no esperes que el
rendimiento con tablas particionadas sea equivalente, porque mientras
esas optimizaciones no estén, no lo es.
Re: Interfaz de usuario del Index Adviser de Gurjeet Singh.
Yessica Brinkmann escribió: > Pueden leer acerca del tema en el link siguiente: > https://github.com/gurjeet/pg_adviser/blob/master/index_adviser/README.index_adviser > El caso es que para poder usar dicha interfaz primeramente debo instalarla. > Y tiene un Makefile. > Yo traté de instalar, pero me aparecen los siguientes errores: > root@debian:/home/yessica/Descargas/postgresql-8.3.23/contrib/pg_adviser_master/pg_advise# > USE_PGXS = 1 make Hola, es difícil encontrar paquetes para Postgres 8.3 porque es demasiado antiguo. Pero si realmente quieres usar el Postgres 8.3 que tienes instalado, no necesitas instalar ningún paquete; basta con hacer que el ejecutable pg_config de tu instalación esté disponible en el PATH para que el "make" lo pueda encontrar. Es decir, tienes que hacer export PATH=$PATH:/usr/local/bin/ donde el "/usr/local/bin" puede ser alguna otra ruta donde estén los ejecutables de postgres 8.3 que ya instalaste. Luego ejecuta el make make USE_PGXS=1 y debería funcionar.
Re: performance de ejecucion de triggers hay alguna penalidad este es mi caso
Jose Mercedes Venegas Acevedo escribió: > Estoy moviendo mi BD a postgres 13 y estoy aprovechando para hacer algunos > ajustes actualmente tengo un conjunto de triggers comunes para unas 250 > tablas que clasifican objetos geométricos el tema es que estas asignaciones > automaticas estan empezando a crecer porque tengo casos en los que ejecuto > digamos hasta 12 trigers por cada insercion de registro y como se trata de > informacion geografica en ocasiones se insertar en numeros de miles de > registros. Hola José, en general no vale la pena optimizar multiples triggers para convertirlos en uno solo, asumiendo que son triggers BEFORE que modifican NEW, es decir no estás haciendo reales UPDATE en el trigger sino modificando el registro en memoria. Seguramente si haces un "micro-benchmark" vas a poder medir una diferencia de llamar un trigger que hace 5 cosas en vez de cinco triggers que hacen una cosa cada uno; pero en la práctica es difícil que esa diferencia tenga importancia. Ahora, si se trata de registros AFTER que hacen otras operaciones, por ejemplo un INSERT o un UPDATE en otra tabla, entonces sí te puede convenir mezclar varios triggers en uno solo, si es que eso te permite reducir la cantidad de operaciones totales. Pero si cada trigger hace operaciones separadas, entonces la cantidad de triggers tampoco debería importar mucho. Si tienes constraints DEFERRED también cambia la respuesta. Saludos
Re: RE: Consulta hit ratio
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 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
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: Re: problema con barman y rsync
Martín Díaz escribió: >Martín Díaz >mardia...@yahoo.com.ar Estimados, ¡No abrir este archivo! Contiene un virus. Recomiendo borrarlo de inmediato. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: Duda con un select y alias
Guillermo E. Villanueva escribió: > Qué pasa si la función a llamar tiene parámetros que dependen de cada fila > de la consulta, por ejemplo : > create or replace function fn_test(x int) returns int > language plpgsql as > $$ > begin raise notice 'buu!'; > return x*4; > end > $$; > > select fn_test(price::int),price > from products p2 > where fn_test(price::int) > 6 > limit 100; > > en ese caso puedo hacer algo para llamar a la función una sola vez por cada > fila? solo se me ocurre un cálculo auxiliar con subconsulta a nivel de > from, pero termina siendo mas complejo para el motor que ejecutar dos veces > la función por cada fila :-) Puedes usar una subconsulta con una "barrera de optimización". Primero pones la subconsulta, que da esto: select fn, price from (select fn_test(price) as fn, price from products) AS sc where fn > 6 LIMIT 100; Pero eso puede no darte el resultado que quieres porque el optimizador "aplana" la subconsulta convirtiéndola en parte de la consulta externa, o sea que los "fn" de la consulta externa igual se convierten en la invocación de fn_test(price). Para evitar eso agregas una barrera de optimización que es OFFSET 0: select fn, price from (select fn_test(price) as fn, price from products OFFSET 0) AS sc where fn > 6 LIMIT 100; Eso le quita libertad al optimizador. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: Duda con un select y alias
Guillermo E. Villanueva escribió: > Creo que entiendo la duda de Daniel, el quiere que por cada tupla del > resultado se llame una única vez a una función y a ese resultado poder > usarlo en mas de una proyección de columna y por ejemplo en el where y en > este caso con lo que indica Jairo no lo solucionaría.s Perdona que te contradiga, pero la solución de Jairo lo soluciona perfectamente. Es fácil verlo haciendo que la función deje una traza en cada ejecución: =# create function f_articulo_get_precio(int) returns text language plpgsql as $$ begin raise notice 'buu!'; return '12342020/09/07'; end $$; CREATE FUNCTION por ejemplo, invocándola una vez vemos la traza: =# select f_articulo_get_precio(1234); NOTICE: buu! f_articulo_get_precio ─── 12342020/09/07 (1 fila) y ahora ejecutamos como Jairo sugiere, la traza aparece una única vez: =# with T1 as (select f_articulo_get_precio(1234) as ls_numero) select substr(ls_numero, 8, 13), substr(ls_numero, 21, 10) from t1 ; NOTICE: buu! substr │ substr ─┼ 0/09/07 │ (1 fila) > (* tampoco lo puede resolver con lo que indica Anthony*) Dicho lo anterior, la solución de Anthony es la realmente inteligente. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: Gran latency en replication/pg_basebackup setup
Hellmuth Vargas escribió: > hay una máxima que no pasa de moda > > "Nunca subestimes el ancho de banda de un camión cargado de Disquetes" Hmm, está modernizada tu versión de la máxima! Yo la había escuchado con un "camión cargado de cintas" (de respaldo, se entiende). > Hace 15 días tenía que crear una réplica en una ubicación remota, sólo > 160GB!! Pero el canal no daba, llevaba 8 horas y sólo había avanzado 40Gb y > se había cancelado por una desconexión: tomamos un disco duro externo, > copiamos otra réplica, en una hora estuvo en la ubicación destino, copiamos > el backup y arriba a sincronizar, el canal si da para los WAL y esta > trabajando hace 7 días! Buena anécdota. Saludos -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: Error pg_restore
Jairo Graterón escribió: > Acabo de observar que postgresql no corre directamente en el SO, están > usando dokku > y que al abrir una conexión se crea un proceso > > socat -t 1 TCP4-LISTEN:5432,fork,reuseaddr TCP4:172.17.0.2:5432 Hmm, yo no tengo idea lo que significa esto, pero el error de SSL sugiere que tienes un problema de red. El timeout ridículo que están pasando como argumento al socat puede ser indicativo de que algo no anda bien ahí y por eso pusieron esa opción. (Ese valor sugiere que la persona que lo hizo no leyó el manual, o que no entendió lo que ahí decía). En el github de "dokku", la interfaz de búsqueda de github no encuentra ninguna coincidencia para "socat" ... aunque quizás es algo que hace Docker mismo. Puede que tu solución sea huir como de la plaga. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: problema con barman y rsync
Guillermo E. Villanueva escribió: > Alvaro, internamente barman lanza un rsync desde barman trayendo datos de > postgres? > O hace que inicie un rsync desde postgres hacia el (barman)? No lo tengo 100% seguro, pero me parece mucho más complicado hacer lo segundo, así que me inclino a pensar que es lo primero. > Acá También sospechamos de red pero entre dos maquinas virtuales en el > mismo hard? 🤔 Bueno, mi sugerencia se mantiene: prueba lanzando el rsync a mano a ver qué sucede. A mí me llama mucho la atención que deje de funcionar a los 64 GB. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: problema con barman y rsync
Guillermo E. Villanueva escribió: > Buen día, por favor si me pueden dar una mano para detectar el problema, > tengo un barman haciendo backup de varios servidores postgres. > Funciona bien con 3 servidores, hay un 4to server postgres que no estoy > pudiendo hacer el base backup (barman backup nombre_server) ya que rsync > está reportando un error. Hola > *2020-08-21 11:51:10,233 [56775] barman.copy_controller WARNING: Failure > executing rsync on remote PGDATA directory: /home/postgres/data/ (attempt > 0)2020-08-21 11:51:10,234 [56775] barman.copy_controller WARNING: Retrying > in 30 seconds2020-08-21 11:59:54,925 [56775] barman.copy_controller Extraño. Es rsync el que tiene el problema. ¿has mirado en los logs del otro lado a ver si rsync deja algo? Parece como si hubiera un problema intermitente en la red, que hace que rsync transfiera una buena cantidad de datos pero se atora. Es posible que sea tu equipamiento de red que no está reaccionando apropiadamente: > *>f+ base/145250215/145250989.19>f+ > base/145250215/145250989.2>f+ > base/145250215/145250989.20>f+ > base/145250215/145250989.21>f+ > base/145250215/145250989.22client_loop: send disconnect: Broken pipersync: > connection unexpectedly closed (68618524218 bytes received so far) > [receiver]rsync error: error in rsync protocol data stream (code 12) at > io.c(226) [receiver=3.1.3]rsync: connection unexpectedly closed (69526 > bytes received so far) [generator]rsync error: unexplained error (code 255) > at io.c(226) [generator=3.1.3]* Se muere como 100 MB antes de llegar a los 64 GB. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: problema para sustituir una master con una replica
Hellmuth Vargas escribió: > Hola lista tengo un PostgreSQL 9.5.9 9.5.23 es lo más reciente. La cantidad de errores que puede haberse corregido en todo ese tiempo (tres años menos ocho días) no quiero ni pensarlo. Actualiza todo y prueba de nuevo; si persiste nos cuentas. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: Consulta sobre WAL
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: alternativa pg_xlog_replay_pause
kernel escribió: > He instalado postgresql version 11 y ahora me dice que no existe la funcion > > ERROR: function pg_xlog_replay_pause() does not exist > LÍNEA 1: SELECT pg_xlog_replay_pause() Todas las funciones que tenían "xlog" en el nombre fueron cambiadas a que usen "wal" en reemplazo. Creo que esto pasó en Postgres 10. Saludos -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: uso de Include en los indices
Hellmuth Vargas escribió: > Hola Diego > > Gracias por la respuesta, pero.. y qué ventaja tendria? pues lo mismo se > logra con un índice compuesto e incluso este último permitirá filtrar > además por el otro campo, e incluso el optimizador prefirió el índice > compuesto. Por ejemplo puedes incluir columnas adicionales en índices UNIQUE (en las cuales no se verificará unicidad), o incluir columnas que no son indexables. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: prueba de jit en postgres 11
Hellmuth Vargas escribió: > Hola Alvaro > > Muchas Gracias por la respuesta, el rendimiento de la máquina no fue el > esperado, la carga de cpu subió muchísimo Hola, esto suena a que debe haber habido algún bug, o le diste demasiada carga a la máquina. Si es un bug, lo ideal es aislar el culpable y reportarlo para que los devels puedan encontrar y corregir el problema. > y algunas consultas triviales se demoran demasiado, Seguramente esto fue por el exceso de carga. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: Cambio de servidor primario
Carlos Damián Hernández escribió: > Estimados buenos día para todos > > En un escenario de 2 servidores en version 11.7 con un master y un > slave en hot standby donde la aplicación apunta al master y al slave > solo van consultas grandes surge los siguiente: > > Debo bajar el master y enviar mi aplicación al slave, que por un > tiempo será el único servidor. > > Que consideraciones debería tener al momento de bajar el master ? y > cuales a a la hora de volver al escenario inicial? Creo que el procedimiento es algo así: 1. Pones pgbouncer en pausa 2. le dices a repmgr que haga el promote 3. reconfiguras el pgbouncer para que apunte al primario-que-era-réplica 4. le sacas la pausa a pgbouncer -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: prueba de jit en postgres 11
Hellmuth Vargas escribió: Hola > Entiendo que JIT básicamente aplica para la optimización de consultas > (diciéndolo de forma coloquiar) Sí, la idea es que algunos pasos en la ejecución de consultas se pueden "compilar" a código específico para esa operación específica, lo que resulta más eficiente que ejecutar el código genérico. Pero se incurre en un costo de hacer esa compilación. Si se va a ejecutar pocas veces, no vale la pena hacer la compilación, porque el menor tiempo de ejecución lo vas a perder en la compilación. > Tengo varias preguntas: > > - Los datos o en general la replica puede llegar a corromperse (porque la > master no tiene jit) o si eventualmente llega a ser master (promoviéndola), > las replicas existentes podrían apuntar a esta? Por diseño, las réplicas nunca escriben datos, así que aún si hubiera un tremendo bug en el JIT no es posible que resulte en corrupción de datos si lo ejecutas en una réplica. Por otra parte, el JIT actualmente sólo se aplica en operaciones de lectura, no en escrituras, así que aún si lo pusieras en el primario, no es posible que resulte en corrupción. La única opción para que tengas un problema de ese tipo es que JIT tenga algún bug que cause que el sistema se caiga. Esto no es imposible pero yo no he visto reportes de que esto haya sucedido. > - los valores por defecto de los parámetros jit_above_cost, > jit_inline_above_cost y jit_optimize_above_cost son altos, en general no > se encuentra mucha información para la configuración de estos, que valores > deberían establecerse (por criterios como RAM, o CPU o tipo de disco duro, > etc como se hacer con otros parámetros).. o debo tomar algunas de las > consultas pesadas y empezar a jugar con estos? Sí, experimentar es lo mejor. Piensa que el tiempo de compilación es de unos cuantos cientos de milisegundos, así que una consulta rápida no se verá beneficiada. Las operaciones que actualmente se optimizan son: 1. "deforming" de tuplas (es decir, convertir la representación "muchos bytes en disco" de una tupla separándola en los valores de cada columna) 2. ejecución de expresiones (es decir, tomar cosas como "columna + 10" y convertirla en código nativo de CPU que ejecuta la suma de dos valores donde uno es constante y el otro se lee de la tupla) -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: Empezando con Slony
Fontana Daniel C (Desartec S.R.L.) escribió: > Estoy comenzando PostgreSQL version 10 y con SLONY 2.2.6 (un maestro y un > solo esclavo para pruebas), tengo algunas dudas. Quisiera saber que grupo > específico, si lo hay, es sobre SLONY? Slony está obsoleto. Usa la replicación lógica nativa[1] de Postgres en vez de eso; tiene mucho mejor rendimiento y es más fácil de manejar, aunque no tiene todas las capacidades. Si te encuentras con alguna limitación que es imposible de solventar con la replicación nativa, dale una mirada a pglogical[2]. [1] https://www.postgresql.org/docs/12/logical-replication.html [2] https://www.2ndquadrant.com/es/resources/pglogical/ -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: localizar sentencia en archivos wal
kernel escribió: > Hola, > > Me me han desaparecido los datos de una tabla, por suerte teníamos copia de > seguridad y ya lo hemos restaurado. > > La cuestión es que no sabemos por que ha podido suceder , no sabemos si ha > podido ser el ERP o algún usuario de administración del al db lo haya > borrado por error > > Disponemos de una copia base y de todos los archivos wal, ¿hay alguna manera > de poder buscar las sentencias en estos archivos wal para poder tirar del > hilo? Sí, se puede seguir el hilo, pero como dijo Martín es a nivel físico. Lo primero es obtener el relfilenode de la tabla (de pg_class) y el ctid de la tupla que quieres investigar. Luego usa pg_waldump (o pg_xlogdump en versiones anteriores) para encontrar qué le hizo update o delete a esa tupla en ese relfilenode. Eso te dará un XID (identificador de transacción). Puedes ver qué más hizo esa transacción usando pg_waldump -x. Si tu log_line_prefix tiene %x entonces podrás ver lo que dejó en el log esa transacción (por ej. cuándo se conectó, desde qué IP, etc). -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: problema al intentar recuperar PITR
Martín Marqués escribió: > Mas que recomendar usar rsync, mejor instalar barman y ahorrarse tantos > dolores de cabeza! Sí, yo pensé lo mismo desde hace bastantes mails en este hilo. Escribir archive_commands y restore_commands no es fácil, aunque lo parezca. Los ejemplos de la documentación tienen problemas :-( -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: Problema de conexion Postgres y Prestashop
Wilson Montero Quiroz escribió: > Estimados, espero su ayuda. > Estoy instalando Prestashop 1.7 y lo quiero enlazar con postgresql 10, ya que > personalmente me gusta esta base de datos en cuanto a rendimiento y demás. Postgres no está soportado por prestashop. https://github.com/PrestaShop/PrestaShop/issues/13512 -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: Problema de conexion Postgres y Prestashop
Wilson Montero Quiroz escribió: > Estimados, espero su ayuda. > Estoy instalando Prestashop 1.7 y lo quiero enlazar con postgresql 10, ya que > personalmente me gusta esta base de datos en cuanto a rendimiento y demás. > Llevo días tratando de conectar la base de datos y siempre me arroja este > error.Database server not found. Please verify the username, password and > server (DbPDO) fields > Crei que era un problema de postgresql rejection, le habilite el ip del > computador desde dnde se esta accediendo al computador en los archivos > posgresql.conf y pg_hba.conf, sin embargo sigo sin poder conectar. Los datos > de usuario, clave y base de datos estan bien. la dirección de conexion esta > 127.0.0.1:5432, inclusive el puerto el habilite en UFW. Se quito los > comentarios en extension=pdo_psql y extension=pgsql, la base de datos es > md5.Probé con dos bases de datos1. encoding = SQL_ASCII, LC_COLLATE AND > LC_TYPE = C2. Utf-8 ¿por qué la dirección es 127.0.0.1:5432? Eso no traduce correctamente. Prueba con 127.0.0.1. Si eso no funciona, muestra un copy&paste de la configuración. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: problema al intentar recuperar PITR
Guillermo E. Villanueva escribió: > Aclaro que pude realizar la restauración del server, pero copiando a mano > los wal al directori pg_xlog ¿qué hay en archive_command? Me pregunto si estarás borrando los WAL cuando los archivas (cosa que, obviamente, no debe hacerse) Saludos -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: probable translation typo
Justin Pryzby escribió: > src/bin/pg_dump/po/es.po:msgstr " --on-confict-do-nothing agregar ON > CONFLICT DO NOTHING a órdenes INSERT\n" > > Should say "on-conflict" with an "ell" You're right, thanks for reporting. Fixing ... -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: Organización masters y réplicas
Francisco Olarte escribió: > La descripcion es un poco incompleta, en opcion 2 ambos o ninguno ( > depende de si vuela el master o la replica ), o sea, el numero > esperado de failovers es el mismo si fallan random. Cierto. > Por otro lado, no se como andan los SSG ahora, pero tengo entendido > que cuando se molestan suelen ser bastante catastroficos fallando ya > de por si, con lo que "ignicion espontanea" puede no ser mala > descripcion ). También es cierto, aunque han mejorado mucho en confiabilidad. Me imagino que habrán puesto algún tipo de RAID. > Lo que comentas es por otro lado correcto considerando el peor caso, > que es el que IMHO hay que mirar aqui ( suponiendo servidores iguales > para el resto de parametros, ya que solo descriube el disco, y ademas > tiene pinta de que estan cercanos ). Si se inunda o derrumba el datacenter, ya es harina de otro costal :-) > Yo añadiria ademas que la opcion 1, puede ayudar a equilibrar la > carga, pero ahi habria que medir, no sea que, p.e., los reports se > hagan a distintas horas siempre o cosas de esas. Pero sin mas datos, > habria que suponer BD iguales, mismo acceso, se reparte mejor. Sí, eso es algo que analizar también. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: Organización masters y réplicas
Hellmuth Vargas escribió: > Quieren migrar otra de sus bases de datos a estos nuevos servidores y > plantean si poner cruzados las máster y réplicas... Osea > > Opción 1: > equipo 1: máster 1, réplica 2 > Equipo 2: máster 2, réplica 1 > > Opcion 2: > equipo 1: máster 1, máster 2 > Equipo 2: replica1, réplica 2 Hola, una consideración importante es qué sucede si una máquina recibe un impacto de meteorito, estalla, o hace ignición espontánea (etc, se entiende). En opción2, ambos clústers tendrán que hacer failover; en opción1 sólo uno de ellos lo hará. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: log de sentencias SQL
Guillermo E. Villanueva escribió: > Hola Alvaro, actualmente lo está registrando así el log: > linea 200 - UDPATE col1=$1 WHERE col2=$2 > linea 201 - . DETAIL: Parameters: $1 = '\x255. y ahí > viene todo el chorizo de contenido del bytea y luego el parámetro $2 > > A la aplicación no la hacemos nosotros, pero que tipo de sentencia puedo > sugerir? alguna referencia url para pasar el contenido bytea por separado? Eh, en ese caso, el parámetro ya se está pasando por separado -- no hay forma de limitarlo. Justo en Postgres 13 agregamos unos parámetros para configurar el largo máximo de parámetros que se mandan al log. Obviamente sería bueno que lo probaras en cuanto salga el primer beta (o incluso lo puedes probar ahora mismo) para verificar que el comportamiento es el que tú quieres. Puedes verlo aquí: https://www.postgresql.org/docs/devel/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-WHAT bajo el nombre log_parameter_max_length y log_parameter_max_length_on_error. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: log de sentencias SQL
Guillermo E. Villanueva escribió: > Hola buenas tardes > En un servidor en producción estamos haciendo temporalmente log de todas > las sentencias SQL. > Un problema es que tenemos una tabla con un campo bytea y cada vez que hay > un insert o update sobre ese campo, se transcribe en el log el contenido > completo del campo bytea . Existe alguna forma de evitar esto? que si se > haga log de las sentencias, pero en el caso de campo bytea trunque la > sentencia o alguna solución similar? No que yo sepa. Lo que podrías hacer es cambiar la sentencia para que el bytea se envíe como un parámetro separado en vez de venir interpolado en la cadena de la consulta. Eso es algo que tienes que cambiar en la aplicación. De todos modos es buena idea, porque ahorra bastante trabajo ... -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: Arranque automático
Guillermo E. Villanueva escribió: > El lun., 9 mar. 2020 a las 14:45, Alvaro Herrera () > escribió: > > Hmm, esto está desactualizado. Deberías estar usando el archivo > > .service para systemd, no los scripts antiguos sysv. > > > *Yo estaba usando el que descargué junto con los fuentes del directorio > contrib el .service también está disponible junto con los fuentes?* No, viene con paquetes. Puedes copiarlo de allá. > 'su' si está Alvaro, y funciona desde línea de comandos. > *Probé de ponerle el path completo, pero no funca tampoco, error con código > 126 ahora* man su: EXIT STATUS 126The requested command could not be executed Posiblemente limitación de selinux o algo similar. ¿Deberías marcar el ejecutable con la etiqueta apropiada? -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: Arranque automático
Guillermo E. Villanueva escribió: > Buenos días, instalé desde fuentes postgres 12 sobre centos 8 > Copié el script de inicio desde contrib/start-scripts hacia el directorio > ...init.d > > Postgres inicia sin problemas con pg_ctl y también con la línea de comandos > service postgres start Hmm, esto está desactualizado. Deberías estar usando el archivo .service para systemd, no los scripts antiguos sysv. > El código de la línea mencionada en el mensaje de error (línea 94) es: > su - $PGUSER -c "$DAEMON_ENV $DAEMON -D '$PGDATA' >>$PGLOG 2>&1 &" > mar 09 12:36:46 centos8 postgres[875]: Starting PostgreSQL: > /etc/rc.d/init.d/postgres: línea 94: su: no se encontró la orden Esto significa que 'su' no está o no puede encontrarse por alguna razón. ¿Quizás no tienes instalado el paquete util-linux (me parecería muy raro)? Quizás el script no tiene en PATH la ubicación de 'su'. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: Exportacion por lotes
On 2020-Mar-03, Hernan Jesus Gonzalez Carmona wrote: > Estimados antes que todo me presento, mi nombre es Hernan Gonzalez, me > acabo de inscribir en esta lista de correo y desde ya me disculpo si en > este mensaje violo alguna normativa de la lista de correo pero necesito > ayuda que me apura mucho. > > Quien me podria ayudar con información respecto de como exportar una > consulta en distintos archivos según una condición determinada y que cada > archivo tenga el nombre de dicha condición, es decir, si tengo una tabla > con 100 registros y uno de los campos tiene un dominio de 4 valor > distintos, necesito generar 4 archivos cada uno con nombre de cada valor > posible de dicho campo, y que la suma de los registros de los 4 archivos > sea 100 Hernán, tu mensaje no viola ninguna norma, pero la lista pgsql-general trafica en inglés. Para preguntas en castellano puedes usar la lista pgsql-es-ayuda (en copia). No indicaste qué herramienta quieres usar para lograr tu resultado. Por ejemplo si puedes usar bash, podrías hacer algo como #!/bin/bash valores=$(psql -At --no-psqlrc -c "select distinct valores from tabla") for i in $valores; do psql -At --no-psqlrc -o "resultados-$i.txt" -c "select * from tabla where valores = '$i'" done -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: SCHEMAS DESAPARECIDOS
Flor Avila escribió: > Gracias, por la pronta respuesta, el respaldo no es el problema, el > problema es porque no los encuentro o no los muestra postgres porque estan > con un problema y me gustaria saber como los recupero o que paso para que > no vuelva a pasar. Es posible que te hayan crackeado el servidor ... ya hemos visto un par de casos acá en esta lista y en otros lugares. No sería mucha sorpresa que tuvieras problemas de seguridad sin parchar en tu servidor, sobre todo con la evidencia que indica que sigues usando una versión de Postgres dos años después que ya no está soportada por la comunidad (y por lo tanto tiene agujeros de seguridad conocidos y explotables). En resumen: yo aconsejaría reinstalar todo en máquinas limpias, usando versiones soportadas del sistema operativo y Postgres, sin agujeros de seguridad, y restaurar backups. Formatea completa esa máquina porque si alguien se metió es seguro que puso más de un "backdoor". Saludos -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: SCHEMAS DESAPARECIDOS
Flor Avila escribió: > Por favor agradeceria si me ayudan, hoy ingrese a mi server y ya no > encontre schemas en mi server, ni el publico ni otro, que puedo hacer tengo > el postgres 9.3 ¿tienes backups? -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: Que tan cierto es sobre este virus de postgresql..
Micky Khan escribió: > ALERTA NUEVO VIRUS QUE ATACA LAS BASE DE DATOS POSTGRESQL ELIMINA TODA LA > INFORMACIÓN Y CREA UNA TABLA CON EL NOMBRE "WARNING" DONDE ALMACENA LA > INFORMACION DE CUANTO SE TIENE QUE PAGAR EN BITCOIN PARA RECUPERAR LA > INFORMACIÓN > [https://www.bitcoinabuse.com/…/1KnMcEqCTvQfMzEgnvfZvyprLPc2…](https://www.bitcoinabuse.com/reports/1KnMcEqCTvQfMzEgnvfZvyprLPc2bnvMm8?fbclid=IwAR3880p0ZlkR-kWRUg3WjrbJBALF-umrcZsppE54MfkOKgH5vrvAT5iQ2Iw) :-( Hace poco tuvimos en esta lista un reporte de alguien a quien le tomaron la BD de rehén. La sugerencia obvia es mantener todo el software al día (Postgres y el sistema operativo), tener los firewalls apropiados, no dejar permisos "trust", restringir lo más posible los accesos de superusuario, etc. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: saber que filas se actualizaron o insertaron con upsert
mauricio pullabuestan escribió: > Buen día > > Tengo una tabla a la cual envió un json para insertar o actualizar > registros, me interesa mediante returing insertar en una tabla > temporal los registros afectados y de alguna forma poder distinguir > cuales se insertaron o actualizaron para poder interactuar después. Estoy casi seguro que INSERT ON CONFLICT DO UPDATE no tiene ninguna manera de distinguir registros que fueron insertados de aquellos que fueron actualizados. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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
Re: procesos que no terminan
Jose Mercedes Venegas Acevedo escribió: > Buen dia a todos > > recientemente consulte la tabla de actividad de postgres y resulta que > encontre estos 3 procesos Hola, esos procesos son normales y necesarios para la operación de Postgres. No los mates. El que reportan que usan muchos GB de memoria se debe a que el sistema operativo cuenta los accesos a memoria compartida(*). Pero la cantidad de memoria privada que usan es poca. No debe preocuparte. (*) pero sólo se cuenta a medida que la acceden. Por eso al principio reportan muy bajo uso, y va creciendo paulatinamente. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: reconstruir indices
Romero, Fernando escribió: > Hola como están. > Necesito reconstruir todos los índices de una base de datos, pero me da error > la sintaxis. > > ERROR: can only reindex the currently open database > > La sintaxis es reindex database "nombredela basededatos"; Tienes que estar conectado a la base de datos "nombredela basededatos". No funciona si estás conectado a otra. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: Ransomware
Victor Báez escribió: > Alvaro > Sabes de alguien que pago y que le decodificaron? No, pero tú mismo ya dijiste que el "hacker" te mandó el archivo decodificado, lo que significa que por lo menos es verdad que tiene la llave. USD3000 parece un precio razonable por un curso express de mantener buenos backups (y los servidores importantes parchados y bien aislados de la red). > No tengo mucha confianza pero no tengo opciones En este caso, no veo que haya jurisdicción para perseguir al criminal, así que no sé qué recurso podrías tener. O pagas, o te jodes. Yo nunca le he tenido mucha confianza al tema de los bitcoins, y he visto que esta es la aplicación más exitosa que han tenido: actividad criminal imposible de perseguir judicialmente. Si no existieran bitcoins y se viera obligado a usar una cuenta de banco o Paypal o algo así, sería perseguible. Los lavadores de dinero, narcotraficantes, traficantes de órganos (menores), "blancas", etc son los más beneficiados. Mientras tanto una fracción de la humanidad se siente feliz por llenar sus cuentas de banco "minando bitcoins" ... (Sí, es verdad que esa actividad criminal siempre ha existido y no va a dejar de existir si es que llegaran a eliminarse completamente las criptomonedas; pero no veo por qué hacerles la vida más fácil). -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: Ransomware
Horacio Miranda escribió: > Igual anota el bitcoind y hace la denuncia. ¿a qué autoridad? -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
