From: | "Igor Neyman" <ineyman(at)perceptron(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: parallel option in pg_restore |
Date: | 2010-06-22 18:48:51 |
Message-ID: | F4C27E77F7A33E4CA98C19A9DC6722A206252106@EXCHANGE.corp.perceptron.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> Sent: Tuesday, June 22, 2010 2:41 PM
> To: Igor Neyman
> Cc: pgsql-admin(at)postgresql(dot)org
> Subject: Re: [ADMIN] parallel option in pg_restore
>
> "Igor Neyman" <ineyman(at)perceptron(dot)com> writes:
> > Attached is script that could be used to pre-create "parent" tables
> > (from which partitions were inherited).
>
> Thanks. Now that I dig into it, it looks like the actual
> trigger for the problem is that pg_dump, not pg_restore,
> couldn't seek while it was creating the dump file --- so it
> didn't seek back and update the file's table-of-contents with
> exact dump offsets. What command did you use to create the
> dump file, exactly?
>
> regards, tom lane
>
>
Here is the backup script to backup all partitions for specific month
(200907) in one backup file:
SETLOCAL
set PGPASSFILE=%PGINSTALL%\DB_scripts\postgres.pgpass
SET PGBACKUPDRIVE=%PGBACKUP%
pg_dump -U vec_dba -F c -f
%PGBACKUPDRIVE%\PartitionedBackup\CM_200907.bac -v -Z 9 -t *200907
vector 2>> %PGBACKUPDRIVE%\Backup\Log\DB_Backup.log
ENDLOCAL
This script is a part of "bigger" backup, which backs up other
non-partitioned tables as well.
Regards,
Igor Neyman
From | Date | Subject | |
---|---|---|---|
Next Message | Balkrishna Sharma | 2010-06-23 03:36:32 | Re: db recovery after raid5 failure |
Previous Message | Tom Lane | 2010-06-22 18:40:39 | Re: parallel option in pg_restore |