Skip site navigation (1) Skip section navigation (2)

Re: parallel option in pg_restore

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: (view raw, whole thread or download thread mbox)
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:

set PGPASSFILE=%PGINSTALL%\DB_scripts\postgres.pgpass

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


This script is a part of "bigger" backup, which backs up other
non-partitioned tables as well.

Igor Neyman

In response to

pgsql-admin by date

Next:From: Balkrishna SharmaDate: 2010-06-23 03:36:32
Subject: Re: db recovery after raid5 failure
Previous:From: Tom LaneDate: 2010-06-22 18:40:39
Subject: Re: parallel option in pg_restore

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group