Carlos T. Groero Carmona escribió:
> Yep, no voy a perder mas tiempo, voy a empezar nuevamente my pg_basebackup,
> ya remov'i la razon por la cual fallo, asi que lo empezare nuevamente.
>
> Por cierto, algo curioso qu eme paso cuando empece pg_basebackup es que se
> quedaba esperando por el checkp
Yep, no voy a perder mas tiempo, voy a empezar nuevamente my pg_basebackup,
ya remov'i la razon por la cual fallo, asi que lo empezare nuevamente.
Por cierto, algo curioso qu eme paso cuando empece pg_basebackup es que se
quedaba esperando por el checkpoint demasiado tiempo y entonces decia que
el
Carlos T. Groero Carmona escribió:
> Hola lista,
>
> Estaba realizando un pg_basebackup y casi terminando 99.9% falla debido a
> que tenia una copia del postgresql.conf hecha con el usuario root y
> entonces el pg_basebackup no pudo completar el proceso.
Ja, hemos pasado por eso. Es error de pil
Copie los archivos que me faltaban ~/global/pg_control y postgres
inicializ'o, pero al checkear los logs veo que no puede terminar de
levantar porque:
2019-09-10 10:53:40 CDT [26264]: user=,db=,app=,client=,trans=0 LOG:
0: started streaming WAL from primary at ABCC/7D00 on timeline 1
2019-
En mi caso por lo general manejo los tiempo de borrado de los wal al
menos lo configure para que duren 3 días.
Revisa eso, sino debes buscar una salva de días anteriores si no has
tenido muchos movimiento de los datos, Ahora yo te recomendé copiar todo
la carpeta "data" y pegarla en tu nodos s
Lautaro Palamidessi escribió:
> OK, quedó claro: son utiles en tiempo de ejecucion, pero al scriptearlas
> trae estas (para mí) sorpresas.
> Creí que "el momento de ejecutarse" era su invocacion con SELECT, no su
> CREATE.
Bueno, la ejecución *es* cuando lees la vista con SELECT :-) Por
ejemplo s
Si basicamente, voy a copiar global/pg_global que es lo que me falto.
Con eso debo resolver.
Gracias,
Carlos
On Tue, Sep 10, 2019, 8:37 AM wrote:
>
> Hola,
>
> Tampoco sé si te funcionará a ti, pero una vez tuve que para el servicio
> del master y copiar físicamente toda las carpeta y luego pe
Hola,
Tampoco sé si te funcionará a ti, pero una vez tuve que para el servicio
del master y copiar físicamente toda las carpeta y luego pegarla en
todos mis sever secundarios.
Luego los fue levantando, previa revisión de las configuraciones y me
funciono.
El 2019-09-10 09:26, Carlos T.
OK, quedó claro: son utiles en tiempo de ejecucion, pero al scriptearlas
trae estas (para mí) sorpresas.
Creí que "el momento de ejecutarse" era su invocacion con SELECT, no su
CREATE.
Gracias Alvaro / Anthony !!!
El mar., 10 sept. 2019 a las 10:20, Alvaro Herrera (<
alvhe...@2ndquadrant.com>) e
Hola Lautaro,
Lautaro Palamidessi escribió:
> --y para mi sorpresa veo que devuelve:
> " SELECT prueba.campo_fecha
>FROM prueba
> WHERE ((prueba.campo_fecha >= '2019-09-01 00:00:00'::timestamp without
> time zone) AND (prueba.campo_fecha <= '2019-09-02 00:00:00'::timestamp
> without time zo
Si esa copia ya la movi fuera de mi pgdata, se que pg_basebackup
funcionara, solo queria ver si havia un camino corto pues el pg_basebackup
se demora 22horas para ~2.3TB
Gracias,
Carlos.
On Tue, Sep 10, 2019, 8:23 AM Byron Gallardo wrote:
> si tu error es similar a esto *" pg_basebackup: could
Hola, según la documentación
https://www.postgresql.org/docs/11/datatype-datetime.html#DATATYPE-DATETIME-INPUT
son valores/constantes de entrada del tipo de dato fecha, y que son
convertidos al valor de fecha y tiempo una vez leídos, eso explica tu caso
/...//PostgreSQL//supports several spe
si tu error es similar a esto *" pg_basebackup: could not get write-ahead
log end position from server: ERROR: could not open file
"./postgresql.conf_copy": Permission denied"*, cambia el dueño de tu copia
postgres.conf_copy al usuario postgres y prueba nuevamente
El mar., 10 sept. 2019 a las 2:2
H as mell,eso fue lo q lo hizo fallar, cree una copia del postgres.conf
usando el usuario root, por lo que pg_basebacup no tuvo acceso y se detuvo.
Pero como dice horacio, no creo que haya una manera, el primer requisito
pata pg_basebackup funcione es que la carpeta data este vacia en el standby.
Buenos días lista,
Hace unos días (el 2 de septiembre) tenía que "detectar" en una tabla las
transacciones de "ayer" y si bien lo lógico es usar una función con
parámetros "desde" y "hasta" que las filtre, por adaptar algo que ya
existía tomé para el lado de usar una vista con fechas filtradas ent
Hola, se me ocurren dos cosas rápidas para mirar:
La primera es que pases el mensaje de error, hay un -v de verbose, como
para ir viendo.
La segunda que mires los permisos / owners de los objetos. Típicamente
encontrás cosas con root dentro de la carpeta de postgres y esto lo hace
fallar.
Sa
No veo una opcion para que continue.
On 10/09/2019 4:57 PM, Carlos T. Groero Carmona wrote:
Hola lista,
Estaba realizando un pg_basebackup y casi terminando 99.9% falla
debido a que tenia una copia del postgresql.conf hecha con el usuario
root y entonces el pg_basebackup no pudo completar el
17 matches
Mail list logo
