Merge previous commit.

README.md

@@ -46,7 +46,7 @@ support synchronized snapshots, a feature that was introduced in PG 9.2
 for primary servers and 10 for standbys. pg_dumpbinary will refuse to
 dump database that do not respect these minimum versions.
 
-pg_dumpbinary -j uses multiple database connections; it connects to the
+pg_dumpbinary uses multiple database connections; it connects to the
 database once with the master process to create a synchronized snapshot
 and dump the pre-data section. Once again for each worker job using the
 synchronized snapshot.
@@ -136,13 +136,17 @@ options:
 
 ## Parallel processing
 
-pg_dumpbinary is very performant to generate the dump as it can parallelize
-the dump of all tables following the number of simultaneous process you
-want to use. The behaviour is like the -j option of pg_dump in directory
-format. 
+The speed of the dump can be improved by using parallelism during the
+export by pg_dumpbinary. Set option -j with the number of simultaneous
+process you want to use. The behaviour is like the -j option of pg_dump
+in directory format. 
 
-To enable parallel processing you just have to use the -j N option where N
-is the number of cores you want to use.
+The speed of the restoration can be improved by using parallelism during
+the call to pg_restorebinary. Set option -j with the number of simultaneous
+process you want to use. The behaviour is like the -j option of pg_restore.
+
+The parallelism is also used to restore post-data section for indexes and
+constraints.
 
 ## Binary format
 

doc/pg_dumpbinary.pod

@@ -75,14 +75,10 @@ synchronized snapshot.
 
 =head1 PARALLEL PROCESSING
 
-pg_dumpbinary is very performant to generate the dump as it can parallelize
-the dump of all tables following the number of simultaneous process you
-want to use. The behaviour is like the -j option of pg_dump in directory
-format. Of course it is not as performant as a call to pg_dump in directory
-format.
-
-To enable parallel processing you just have to use the -j N option where N
-is the number of cores you want to use.
+The speed of the dump can be improved by using parallelism during the
+export by pg_dumpbinary. Set option -j with the number of simultaneous
+process you want to use. The behaviour is like the -j option of pg_dump
+in directory format. 
 
 =head1 BINARY FORMAT
 

doc/pg_restorebinary.pod

@@ -53,14 +53,12 @@ by pg_dumpbinary using the -i option.
 
 =head1 PARALLEL PROCESSING
 
-pg_restorebinary is very performant to restore the backup as it can parallelize
-the import of all tables following the number of simultaneous process you want
-to use. The behaviour is like the -j option of pg_dump in directory format. 
+The speed of the restoration can be improved by using parallelism during
+the call to pg_restorebinary. Set option -j with the number of simultaneous
+process you want to use. The behaviour is like the -j option of pg_restore.
 
-To enable parallel processing you just have to use the -j N option where N
-is the number of cores you want to use.
-
-The parallelism is also used to restore post-data section (indexes, constraints).
+The parallelism is also used to restore post-data section for indexes and
+constraints.
 
 =head1 TODO
 

pg_dumpbinary

@@ -376,14 +376,15 @@ sub get_table_list
 {
 	my %tb_lst = ();
 
-	# 197; 1259 57153 TABLE EZ0P T1 gilles
-	# 198; 1259 57159 TABLE public T1 gilles
 	my @list =  `$PGRESTORE -l $OUTDIR/pre-data.dmp | grep " TABLE "`;
 	chomp(@list);
 
 	foreach my $l (@list)
 	{
+		# 198; 1259 57159 TABLE public T1 gilles
+		next if ($l =~ /\d+: \d+ \d+ TABLE /);
 		my @inf = split(/\s/, $l);
+		next if ($#inf != 6);
 		push( @{ $tb_lst{$inf[4]} }, $inf[5]);
 	}