I am just responding on the latest mail on this thread. But the question is about functionality. The proposal is to add a single flag --include-foreign-data which controls whether or not data is dumped for all the foreign tables in a database. That may not serve the purpose. A foreign table may point to a view, materialized view or inheritance tree, and so on. A database can have foreign tables pointing to all of those kinds. Restoring data to a view won't be possible and restoring it into an inheritance tree would insert it into the parent only and not the children. Further, a user may not want the data to be dumped for all the foreign tables since their usages are different esp. considering restore. I think a better option is to extract data in a foreign table using --table if that's the only usage. Otherwise, we need a foreign table level flag indicating whether pg_dump should dump the data for that foreign table or not.
On Wed, Mar 4, 2020 at 12:41 AM David Steele <da...@pgmasters.net> wrote: > Hi Luis, > > On 1/29/20 11:05 AM, Peter Eisentraut wrote: > > On 2020-01-21 10:36, Luis Carril wrote: > >>> Yes we can support --include-foreign-data without parallel option and > >>> later add support for parallel option as a different patch. > >> > >> Hi, > >> > >> I've attached a new version of the patch in which an error is > >> emitted if the parallel backup is used with the --include-foreign-data > >> option. > > > > This seems like an overreaction. The whole point of > > lockTableForWorker() is to avoid deadlocks, but foreign tables don't > > have locks, so it's not a problem. I think you can just skip foreign > > tables in lockTableForWorker() using the same logic that getTables() > uses. > > > > I think parallel data dump would be an especially interesting option > > when using foreign tables, so it's worth figuring this out. > > What do you think of Peter's comment? > > Regards, > -- > -David > da...@pgmasters.net > > > -- Best Wishes, Ashutosh Bapat
