From: | "Guillermo E(dot) Villanueva" <guillermovil(at)gmail(dot)com> |
---|---|
To: | Francisco Olarte <folarte(at)peoplecall(dot)com> |
Cc: | Lista Postgres ES <pgsql-es-ayuda(at)postgresql(dot)org> |
Subject: | Re: pg_restore no restaura |
Date: | 2020-04-24 12:26:24 |
Message-ID: | CANm+PCCOfBFyadmqdYNufmt7ZR8i0gfQRmg-_PLTzBkt1QnxQw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
Gracias Francisco,
El dump que se había transferido por ftp a otro equipo se había hecho
antes, no eran los mismo dump, tenían una diferencia de unas horas.
El dom., 19 abr. 2020 a las 5:56, Francisco Olarte (<folarte(at)peoplecall(dot)com>)
escribió:
> Guillermo:
>
> On Sat, Apr 18, 2020 at 10:21 PM Guillermo E. Villanueva
> <guillermovil(at)gmail(dot)com> wrote:
> > Amigos, muchas gracias por la ayuda, miren gracias a Dios también tenía
> un backup en un servidor externo (lo copiamos todas las noches con ftp)
> probamos con ese y no dió error. Evidentemente el dump también estaba
> corrupto. Lo cual es bastante lógico si lo que estaba mal era el filesystem.
>
> Bueno es saber que arreglose. La cosa es como se te ha estropeado el
> backup entre cuando hiciste el FTP y cuando lo restauraste, pero eso
> es aceite de codos.
>
> ....
> >> Cual de los dos te da out of memory, el primer paso o el segundo?
>
> Siempre que te pase eso es que has encontrado un error en el
> pg_restore ( poco probable ) o un dump corrupto ( lo habitual, e
> incluyo aquí bugs de pg_dump que generen eso de forma repetible ). De
> hecho una forma clásica de verificar un dump es "pg_restore ..... >
> /dev/null" ( o | wc que uso a veces por saber lo que ocuparía en sql
> ).
>
> Francisco Olarte.
>
From | Date | Subject | |
---|---|---|---|
Next Message | Francisco Olarte | 2020-04-24 18:43:46 | Re: pg_restore no restaura |
Previous Message | Francisco Olarte | 2020-04-19 08:55:57 | Re: pg_restore no restaura |