From: | Luis Carril <luis(dot)carril(at)swarm64(dot)com> |
---|---|
To: | vignesh C <vignesh21(at)gmail(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Option to dump foreign data in pg_dump |
Date: | 2020-01-14 11:52:49 |
Message-ID: | LEXPR01MB0255BE703E91227EB9A1E29FE7340@LEXPR01MB0255.DEUPRD01.PROD.OUTLOOK.DE |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 <vignesh21(at)gmail(dot)com>
Sent: Tuesday, January 14, 2020 1:48 AM
To: Luis Carril <luis(dot)carril(at)swarm64(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>; Daniel Gustafsson <daniel(at)yesql(dot)se>; Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>; PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Option to dump foreign data in pg_dump
On Fri, Nov 29, 2019 at 2:10 PM Luis Carril <luis(dot)carril(at)swarm64(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2020-01-14 12:43:22 | Re: [HACKERS] Block level parallel vacuum |
Previous Message | Mahendra Singh Thalor | 2020-01-14 11:46:51 | Re: [HACKERS] Block level parallel vacuum |