Can you have a look at dump with parallel option. Parallel option will take a lock on table while invoking lockTableForWorker. May be this is not required for foreign tables. Thoughts? I tried with -j and found no issue. I guess that the foreign table needs locking anyway to prevent anyone to modify it while is being dumped.
Cheers, Luis M Carril ________________________________ From: vignesh C <vignes...@gmail.com> Sent: Tuesday, January 14, 2020 1:48 AM To: Luis Carril <luis.car...@swarm64.com> Cc: Alvaro Herrera <alvhe...@2ndquadrant.com>; Daniel Gustafsson <dan...@yesql.se>; Laurenz Albe <laurenz.a...@cybertec.at>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org> Subject: Re: Option to dump foreign data in pg_dump On Fri, Nov 29, 2019 at 2:10 PM Luis Carril <luis.car...@swarm64.com> wrote: > > Luis, > > It seems you've got enough support for this concept, so let's move > forward with this patch. There are some comments from Tom about the > patch; would you like to send an updated version perhaps? > > Thanks > > Hi, > > I've attached a new version (v6) removing the superfluous JOIN that Tom > identified, and not collecting the oids (avoiding the query) if the option is > not used at all. > > About the testing issues that Tom mentioned: > I do not see how can we have a pure SQL dummy FDW that tests the > functionality. Because the only way to identify if the data of a foreign > table for the chosen server is dumped is if the COPY statement appears in the > output, but if the C callbacks of the FDW are not implemented, then the > SELECT that dumps the data to generate the COPY cannot be executed. > Also, to test that the include option chooses only the data of the specified > foreign servers we would need some negative testing, i.e. that the COPY > statement for the non-desired table does not appear. But I do not find these > kind of tests in the test suite, even for other selective options like > --table or --exclude-schema. > Can you have a look at dump with parallel option. Parallel option will take a lock on table while invoking lockTableForWorker. May be this is not required for foreign tables. Thoughts? Regards, Vignesh EnterpriseDB: http://www.enterprisedb.com
