On 25/04/2020 12:26 am, Guillermo E. Villanueva wrote:
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.
hace un md5sum a los archivos con eso ves si son iguales o no.
El dom., 19 abr. 2020 a las 5:56, Francisco Olarte
(<fola...@peoplecall.com <mailto:fola...@peoplecall.com>>) escribió:
Guillermo:
On Sat, Apr 18, 2020 at 10:21 PM Guillermo E. Villanueva
<guillermo...@gmail.com <mailto:guillermo...@gmail.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.
--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
