Re: parallel option in pg_restore - Mailing list pgsql-admin

From Igor Neyman
Subject Re: parallel option in pg_restore
Date
Msg-id F4C27E77F7A33E4CA98C19A9DC6722A20625208F@EXCHANGE.corp.perceptron.com
Whole thread Raw
In response to Re: parallel option in pg_restore  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: parallel option in pg_restore  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-admin
> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: Tuesday, June 22, 2010 1:10 PM
> To: Igor Neyman
> Cc: pgsql-admin@postgresql.org
> Subject: Re: [ADMIN] parallel option in pg_restore
>
> "Igor Neyman" <ineyman@perceptron.com> writes:
> > Attached are couple smallish files (I suspect, CM_200909.bac might
> > have just empty tables, no data - but it still produces an errror).
>
> Hmm.  I get
>
> pg_restore: [archiver (db)] Error while PROCESSING TOC:
> pg_restore: [archiver (db)] Error from TOC entry 2741; 1259
> 30866 TABLE gp_cycle_200907 vec_dba
> pg_restore: [archiver (db)] could not execute query: ERROR:
> relation "gp_cycle" does not exist
>     Command was:
> CREATE TABLE gp_cycle_200907 (CONSTRAINT
> gp_cycle_200907_cycle_date_time_check CHECK
> (((cycle_date_time >= '2009-07-01 00:0...
>
> The tables all seem to inherit from tables you omitted from
> the dump, so of course it's not restorable for anyone else.
>
> Now I do see
>
> pg_restore: [custom archiver] dumping a specific TOC data
> block out of order is not supported without ID on this input
> stream (fseek required)
>
> after that, but I'm wondering if this is just a problem in
> error recovery rather than the bug we thought we were looking for.
>
>             regards, tom lane
>
>

Right, like I mentioned, these are partitioned tables.

Attached is script that could be used to pre-create "parent" tables
(from which partitions were inherited).
You run it before restoring backed up partition.

Thank you for taking time to look into this issue.
Regards,
Igor Neyman

Attachment

pgsql-admin by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: postgres query is very slow
Next
From: Tom Lane
Date:
Subject: Re: parallel option in pg_restore