Re: Option to dump foreign data in pg_dump
Luis Carril <[email protected]> Tue, 14 Jan 2020 11:52:49 +0000
| Newsgroups | gmane.comp.db.postgresql.devel.general |
|---|---|
| Message-ID | <LEXPR01MB0255BE703E91227EB9A1E29FE7340@LEXPR01MB0255.DEUPRD01.PROD.OUTLOOK.DE> |
--_000_LEXPR01MB0255BE703E91227EB9A1E29FE7340LEXPR01MB0255DEUP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 lo= cking anyway to prevent anyone to modify it while is being dumped. Cheers, Luis M Carril ________________________________ From: vignesh C <[email protected]> Sent: Tuesday, January 14, 2020 1:48 AM To: Luis Carril <[email protected]> Cc: Alvaro Herrera <[email protected]>; Daniel Gustafsson <daniel@ye= sql.se>; Laurenz Albe <[email protected]>; PostgreSQL Hackers <pgsql= [email protected]> Subject: Re: Option to dump foreign data in pg_dump On Fri, Nov 29, 2019 at 2:10 PM Luis Carril <[email protected]> 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 function= ality. 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 tha= t dumps the data to generate the COPY cannot be executed. > Also, to test that the include option chooses only the data of the speci= fied foreign servers we would need some negative testing, i.e. that the COP= Y statement for the non-desired table does not appear. But I do not find th= ese 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 --_000_LEXPR01MB0255BE703E91227EB9A1E29FE7340LEXPR01MB0255DEUP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo= ttom:0;} </style> </head> <body dir=3D"ltr"> <font size=3D"2"><span style=3D"font-size:11pt"> <blockquote type=3D"cite"><font size=3D"2"><span style=3D"font-size:11pt">C= an you have a look at dump with parallel option. Parallel option will<br> take a lock on table while invoking lockTableForWorker. May be this is<br> not required for foreign tables.<br> Thoughts?</span></font></blockquote> </span></font> <div><font size=3D"2"><span style=3D"font-size:11pt">I tried with -j and fo= und no issue. I guess that the foreign table needs locking anyway to preven= t anyone to modify it while is being dumped.</span></font></div> <div><font size=3D"2"><span style=3D"font-size:11pt"><br> </span></font></div> <div><font size=3D"2"><span style=3D"font-size:11pt">Cheers,<br> </span></font></div> <div><font size=3D"2"><span style=3D"font-size:11pt"><br> </span></font></div> <div><font size=3D"2"><span style=3D"font-size:11pt">Luis M Carril<br> </span></font></div> <div id=3D"appendonsend"></div> <hr style=3D"display:inline-block;width:98%" tabindex=3D"-1"> <div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" st= yle=3D"font-size:11pt" color=3D"#000000"><b>From:</b> vignesh C <vignesh= [email protected]><br> <b>Sent:</b> Tuesday, January 14, 2020 1:48 AM<br> <b>To:</b> Luis Carril <[email protected]><br> <b>Cc:</b> Alvaro Herrera <[email protected]>; Daniel Gustafss= on <[email protected]>; Laurenz Albe <[email protected]>; = PostgreSQL Hackers <[email protected]><br> <b>Subject:</b> Re: Option to dump foreign data in pg_dump</font> <div> </div> </div> <div class=3D"BodyFragment"><font size=3D"2"><span style=3D"font-size:11pt;= "> <div class=3D"PlainText">On Fri, Nov 29, 2019 at 2:10 PM Luis Carril <lu= [email protected]> wrote:<br> ><br> > Luis,<br> ><br> > It seems you've got enough support for this concept, so let's move<br> > forward with this patch. There are some comments from Tom about = the<br> > patch; would you like to send an updated version perhaps?<br> ><br> > Thanks<br> ><br> > Hi,<br> ><br> > I've attached a new version (v6) removing the superfluous JOIN t= hat Tom identified, and not collecting the oids (avoiding the query) if the= option is not used at all.<br> ><br> > About the testing issues that Tom mentioned:<br> > I do not see how can we have a pure SQL dummy FDW that tests the funct= ionality. Because the only way to identify if the data of a foreign table f= or the chosen server is dumped is if the COPY statement appears in the outp= ut, but if the C callbacks of the FDW are not implemented, then the SELECT that dumps the data to generate the C= OPY cannot be executed.<br> > Also, to test that the include option chooses only the data of the&nbs= p; 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.<br> ><br> <br> Can you have a look at dump with parallel option. Parallel option will<br> take a lock on table while invoking lockTableForWorker. May be this is<br> not required for foreign tables.<br> Thoughts?<br> <br> Regards,<br> Vignesh<br> EnterpriseDB: <a href=3D"http://www.enterprisedb.com">http://www.enterprise= db.com</a><br> </div> </span></font></div> </body> </html> --_000_LEXPR01MB0255BE703E91227EB9A1E29FE7340LEXPR01MB0255DEUP_--