Thread: pg_dumpall --exclude-database option

pg_dumpall --exclude-database option

From
Andrew Dunstan
Date:
PFA a patch to provide an --exclude-database option for pg_dumpall. The 
causes pg_dumpall to skip any database whose name matches the argument 
pattern. The option can be used multiple times.


Among other use cases, this is useful where a database name is visible 
but the database is not dumpable by the user. Examples of this occur in 
some managed Postgres services.


I will add this to the September CF.


cheers


andrew


-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Attachment

Re: pg_dumpall --exclude-database option

From
Fabien COELHO
Date:
> Among other use cases, this is useful where a database name is visible but 
> the database is not dumpable by the user. Examples of this occur in some 
> managed Postgres services.

This looks like a reasonable feature.

> I will add this to the September CF.

My 0.02€:

Patch applies cleanly, compiles, and works for me.

A question: would it makes sense to have a symmetrical 
--include-database=PATTERN option as well?

Somehow the option does not make much sense when under -g/-r/-t... maybe 
it should complain, like it does when the others are used together?

ISTM that it would have been better to issue just one query with an OR 
list, but that would require to extend "processSQLNamePattern" a little 
bit. Not sure whether it is worth it.

Function "database_excluded": I'd suggest to consider reusing the
"simple_string_list_member" function instead of reimplementing it in a 
special case.

XML doc: "--exclude-database=dbname", ISTM that 
"--exclude-database=pattern" would be closer to what it is? "Multiple 
database can be matched by writing multiple switches". Sure, but it can 
also be done with a pattern. The documentation seems to assume that the 
argument is one database name, and then changes this afterwards. I'd 
suggest to start by saying that a pattern like psql is expected, and then 
proceed to simply tell that the option can be repeated, instead of 
implying that it is a dbname and then telling that it is a pattern.

The simple list is not freed. Ok, it seems to be part of the design of the 
data structure.

-- 
Fabien.

Re: pg_dumpall --exclude-database option

From
Michael Paquier
Date:
On Fri, Aug 03, 2018 at 11:08:57PM +0200, Fabien COELHO wrote:
> Patch applies cleanly, compiles, and works for me.

Last review has not been addressed, so please note that this has been
marked as returned with feedback.
--
Michael

Attachment

Re: pg_dumpall --exclude-database option

From
Andrew Dunstan
Date:

On 08/03/2018 05:08 PM, Fabien COELHO wrote:
>
>> Among other use cases, this is useful where a database name is 
>> visible but the database is not dumpable by the user. Examples of 
>> this occur in some managed Postgres services.
>
> This looks like a reasonable feature.


Thanks for the review.

>
>> I will add this to the September CF.
>
> My 0.02€:
>
> Patch applies cleanly, compiles, and works for me.
>
> A question: would it makes sense to have a symmetrical 
> --include-database=PATTERN option as well?


I don't think so. If you only want a few databases, just use pg_dump. 
The premise of pg_dumpall is that you want all of them and this switch 
provides for exceptions to that.

>
> Somehow the option does not make much sense when under -g/-r/-t... 
> maybe it should complain, like it does when the others are used together?


Added an error check.

>
> ISTM that it would have been better to issue just one query with an OR 
> list, but that would require to extend "processSQLNamePattern" a 
> little bit. Not sure whether it is worth it.

I don't think it is. This uses the same pattern that is used in 
pg_dump.c for similar switches.

>
> Function "database_excluded": I'd suggest to consider reusing the
> "simple_string_list_member" function instead of reimplementing it in a 
> special case.


done.

>
> XML doc: "--exclude-database=dbname", ISTM that 
> "--exclude-database=pattern" would be closer to what it is? "Multiple 
> database can be matched by writing multiple switches". Sure, but it 
> can also be done with a pattern. The documentation seems to assume 
> that the argument is one database name, and then changes this 
> afterwards. I'd suggest to start by saying that a pattern like psql is 
> expected, and then proceed to simply tell that the option can be 
> repeated, instead of implying that it is a dbname and then telling 
> that it is a pattern.

docco revised.

>
> The simple list is not freed. Ok, it seems to be part of the design of 
> the data structure.

I don't see much point in freeing it.

revised patch attached.

cheers

andrew


-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Attachment

Re: pg_dumpall --exclude-database option

From
Andrew Dunstan
Date:

On 08/03/2018 05:08 PM, Fabien COELHO wrote:
>
>> Among other use cases, this is useful where a database name is 
>> visible but the database is not dumpable by the user. Examples of 
>> this occur in some managed Postgres services.
>
> This looks like a reasonable feature.


Thanks for the review.

>
>> I will add this to the September CF.
>
> My 0.02€:
>
> Patch applies cleanly, compiles, and works for me.
>
> A question: would it makes sense to have a symmetrical 
> --include-database=PATTERN option as well?


I don't think so. If you only want a few databases, just use pg_dump. 
The premise of pg_dumpall is that you want all of them and this switch 
provides for exceptions to that.

>
> Somehow the option does not make much sense when under -g/-r/-t... 
> maybe it should complain, like it does when the others are used together?


Added an error check.

>
> ISTM that it would have been better to issue just one query with an OR 
> list, but that would require to extend "processSQLNamePattern" a 
> little bit. Not sure whether it is worth it.

I don't think it is. This uses the same pattern that is used in 
pg_dump.c for similar switches.

>
> Function "database_excluded": I'd suggest to consider reusing the
> "simple_string_list_member" function instead of reimplementing it in a 
> special case.


done.

>
> XML doc: "--exclude-database=dbname", ISTM that 
> "--exclude-database=pattern" would be closer to what it is? "Multiple 
> database can be matched by writing multiple switches". Sure, but it 
> can also be done with a pattern. The documentation seems to assume 
> that the argument is one database name, and then changes this 
> afterwards. I'd suggest to start by saying that a pattern like psql is 
> expected, and then proceed to simply tell that the option can be 
> repeated, instead of implying that it is a dbname and then telling 
> that it is a pattern.

docco revised.

>
> The simple list is not freed. Ok, it seems to be part of the design of 
> the data structure.

I don't see much point in freeing it.

revised patch attached.

cheers

andrew


-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Re: pg_dumpall --exclude-database option

From
Fabien COELHO
Date:
Hello Andrew,

>> A question: would it makes sense to have a symmetrical 
>> --include-database=PATTERN option as well?
>
> I don't think so. If you only want a few databases, just use pg_dump. The 
> premise of pg_dumpall is that you want all of them and this switch provides 
> for exceptions to that.

Ok, sounds reasonable.

>> Somehow the option does not make much sense when under -g/-r/-t... maybe it 
>> should complain, like it does when the others are used together?
>
> Added an error check.

Ok.

>> ISTM that it would have been better to issue just one query with an OR 
>> list, but that would require to extend "processSQLNamePattern" a little 
>> bit. Not sure whether it is worth it.
>
> I don't think it is. This uses the same pattern that is used in pg_dump.c for 
> similar switches.

Ok.

> revised patch attached.

Patch applies cleanly, compiles, make check ok, pg_dump tap tests ok, doc 
build ok.

Very minor comments:

Missing space after comma:

  + {"exclude-database",required_argument, NULL, 5},

Now that C99 is okay, ISTM that both for loops in expand_dbname_patterns 
could benefit from using loop-local variables:

   for (SimpleStringListCell *cell = ...
   for (int i = ...

About the documentation:

    "When using wildcards, be careful to quote the pattern if needed to prevent
     the shell from expanding the wildcards."

I'd suggest to consider simplifying the end, maybe "to prevent shell 
wildcard expansion".

The feature is not tested per se. Maybe one existing tap test could be 
extended with minimal fuss to use it, eg --exclude-database='[a-z]*' 
should be close to only keeping the global stuff? I noticed an "exclude 
table" test already exists.

-- 
Fabien.


Re: pg_dumpall --exclude-database option

From
Andrew Dunstan
Date:

On 10/13/2018 10:07 AM, Fabien COELHO wrote:
>
> Hello Andrew,
>
>>> A question: would it makes sense to have a symmetrical 
>>> --include-database=PATTERN option as well?
>>
>> I don't think so. If you only want a few databases, just use pg_dump. 
>> The premise of pg_dumpall is that you want all of them and this 
>> switch provides for exceptions to that.
>
> Ok, sounds reasonable.
>
>>> Somehow the option does not make much sense when under -g/-r/-t... 
>>> maybe it should complain, like it does when the others are used 
>>> together?
>>
>> Added an error check.
>
> Ok.
>
>>> ISTM that it would have been better to issue just one query with an 
>>> OR list, but that would require to extend "processSQLNamePattern" a 
>>> little bit. Not sure whether it is worth it.
>>
>> I don't think it is. This uses the same pattern that is used in 
>> pg_dump.c for similar switches.
>
> Ok.
>
>> revised patch attached.
>
> Patch applies cleanly, compiles, make check ok, pg_dump tap tests ok, 
> doc build ok.
>
> Very minor comments:
>
> Missing space after comma:
>
>  + {"exclude-database",required_argument, NULL, 5},
>
> Now that C99 is okay, ISTM that both for loops in 
> expand_dbname_patterns could benefit from using loop-local variables:
>
>   for (SimpleStringListCell *cell = ...
>   for (int i = ...
>
> About the documentation:
>
>    "When using wildcards, be careful to quote the pattern if needed to 
> prevent
>     the shell from expanding the wildcards."
>
> I'd suggest to consider simplifying the end, maybe "to prevent shell 
> wildcard expansion".
>
> The feature is not tested per se. Maybe one existing tap test could be 
> extended with minimal fuss to use it, eg --exclude-database='[a-z]*' 
> should be close to only keeping the global stuff? I noticed an 
> "exclude table" test already exists.
>



This patch addresses all these concerns.

cheers

andrew


-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Attachment

Re: pg_dumpall --exclude-database option

From
Fabien COELHO
Date:
Hello Andrew,

> This patch addresses all these concerns.

Patch v4 applies cleanly, compiles, doc generation ok, global & local 
tests ok.

Tiny comments: there is a useless added blank line at the beginning of the 
added varlistenry.

I have recreated the CF entry and put the patch to ready... but I've must 
have mixed up something because now there are two entries:-(

Could anywone remove the duplicate entry (1859 & 1860 are the same)? 
Peter??

-- 
Fabien.


Re: pg_dumpall --exclude-database option

From
Andrew Dunstan
Date:

On 10/31/2018 12:44 PM, Fabien COELHO wrote:
>
> Hello Andrew,
>
>> This patch addresses all these concerns.
>
> Patch v4 applies cleanly, compiles, doc generation ok, global & local 
> tests ok.
>
> Tiny comments: there is a useless added blank line at the beginning of 
> the added varlistenry.
>
> I have recreated the CF entry and put the patch to ready... but I've 
> must have mixed up something because now there are two entries:-(
>
> Could anywone remove the duplicate entry (1859 & 1860 are the same)? 
> Peter??
>


:-( My fault, I just created a new one.

cheers

andrew

-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



Re: pg_dumpall --exclude-database option

From
Fabien COELHO
Date:
> :-( My fault, I just created a new one.

Hmmm... so did I:-) We did it a few minutes apart. I did not find yours 
when I first searched, then I proceeded to try to move the previous CF 
entry which had been marked as "returned" but this was rejected, so I 
recreated the one without checking whether it had appeared in between.

Hopefully someone can remove it…

-- 
Fabien.

Re: pg_dumpall --exclude-database option

From
Michael Paquier
Date:
On Wed, Oct 31, 2018 at 05:44:26PM +0100, Fabien COELHO wrote:
> Patch v4 applies cleanly, compiles, doc generation ok, global & local tests
> ok.

+# also fails for -r and -t, but it seems pointless to add more tests
for those.
+command_fails_like(
+       [ 'pg_dumpall', '--exclude-database=foo', '--globals-only' ],
+       qr/\Qpg_dumpall: option --exclude-database cannot be used
together with -g\/--globals-only\E/,
+       'pg_dumpall: option --exclude-database cannot be used together
with -g/--globals-only');

Usually testing all combinations is preferred, as well as having one
error message for each pattern, which is also more consistent with all
the other sanity checks in pg_dumpall.c and such.
--
Michael

Attachment

Re: pg_dumpall --exclude-database option

From
Alvaro Herrera
Date:
The comment in expand_dbname_patterns is ungrammatical and mentions
"OID" rather than "name", so I suggest

    /*
     * The loop below might sometimes result in duplicate entries in the
     * output name list, but we don't care.
     */

I'm not sure this is grammatical either:
   exclude databases whose name matches PATTERN
I would have written it like this:
   exclude databases whose names match PATTERN
but I'm not sure (each database has only one name, of course, but aren't
you talking about multiple databases there?)

Other than that, the patch seems fine to me -- I tested and it works as
intended.

Personally I would say "See also expand_table_name_patterns" instead of
"This is similar to code in pg_dump.c for handling matching table names.",
as well as mention this function in expand_table_name_patterns' comment.
(No need to mention expand_schema_name_patterns, since these are
adjacent.)  But this is mostly stylistic and left to your own judgement.

In the long run, I think we should add an option to processSQLNamePattern
to use OR instead of AND, which would fix both this problem as well as
pg_dump's.  I don't think that's important enough to stall this patch.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Re: pg_dumpall --exclude-database option

From
Andrew Dunstan
Date:
On 11/17/18 9:55 AM, Alvaro Herrera wrote:
> The comment in expand_dbname_patterns is ungrammatical and mentions
> "OID" rather than "name", so I suggest
>
>     /*
>      * The loop below might sometimes result in duplicate entries in the
>      * output name list, but we don't care.
>      */


Will fix.



> I'm not sure this is grammatical either:
>     exclude databases whose name matches PATTERN
> I would have written it like this:
>     exclude databases whose names match PATTERN
> but I'm not sure (each database has only one name, of course, but aren't
> you talking about multiple databases there?)



I think the original is grammatical.



> Other than that, the patch seems fine to me -- I tested and it works as
> intended.
>
> Personally I would say "See also expand_table_name_patterns" instead of
> "This is similar to code in pg_dump.c for handling matching table names.",
> as well as mention this function in expand_table_name_patterns' comment.
> (No need to mention expand_schema_name_patterns, since these are
> adjacent.)  But this is mostly stylistic and left to your own judgement.
>
> In the long run, I think we should add an option to processSQLNamePattern
> to use OR instead of AND, which would fix both this problem as well as
> pg_dump's.  I don't think that's important enough to stall this patch.


Thanks for the review.


cheers


andrew

-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



Re: pg_dumpall --exclude-database option

From
Dmitry Dolgov
Date:
> On Sun, Nov 18, 2018 at 7:41 PM Andrew Dunstan <andrew.dunstan@2ndquadrant.com> wrote:
>
> On 11/17/18 9:55 AM, Alvaro Herrera wrote:
> > The comment in expand_dbname_patterns is ungrammatical and mentions
> > "OID" rather than "name", so I suggest
>
> Will fix.
>
> > Other than that, the patch seems fine to me -- I tested and it works as
> > intended.
> >
> > Personally I would say "See also expand_table_name_patterns" instead of
> > "This is similar to code in pg_dump.c for handling matching table names.",
> > as well as mention this function in expand_table_name_patterns' comment.
> > (No need to mention expand_schema_name_patterns, since these are
> > adjacent.)  But this is mostly stylistic and left to your own judgement.
> >
> > In the long run, I think we should add an option to processSQLNamePattern
> > to use OR instead of AND, which would fix both this problem as well as
> > pg_dump's.  I don't think that's important enough to stall this patch.
>
> Thanks for the review.

Unfortunately judging from cfbot output patch needs to be rebased, could you
please post an updated version with those fixes mentioned above?


Re: pg_dumpall --exclude-database option

From
Andrew Dunstan
Date:
On 11/18/18 1:41 PM, Andrew Dunstan wrote:
>
> On 11/17/18 9:55 AM, Alvaro Herrera wrote:
>> The comment in expand_dbname_patterns is ungrammatical and mentions
>> "OID" rather than "name", so I suggest
>>
>>     /*
>>      * The loop below might sometimes result in duplicate entries in the
>>      * output name list, but we don't care.
>>      */
>
>
> Will fix.
>
>
>
>> I'm not sure this is grammatical either:
>>     exclude databases whose name matches PATTERN
>> I would have written it like this:
>>     exclude databases whose names match PATTERN
>> but I'm not sure (each database has only one name, of course, but aren't
>> you talking about multiple databases there?)
>
>
>
> I think the original is grammatical.
>
>
>
>> Other than that, the patch seems fine to me -- I tested and it works as
>> intended.
>>
>> Personally I would say "See also expand_table_name_patterns" instead of
>> "This is similar to code in pg_dump.c for handling matching table 
>> names.",
>> as well as mention this function in expand_table_name_patterns' comment.
>> (No need to mention expand_schema_name_patterns, since these are
>> adjacent.)  But this is mostly stylistic and left to your own judgement.
>>
>> In the long run, I think we should add an option to 
>> processSQLNamePattern
>> to use OR instead of AND, which would fix both this problem as well as
>> pg_dump's.  I don't think that's important enough to stall this patch.
>
>
> Thanks for the review.
>
>
>


Rebased and updated patch attached.


cheers


andrew


-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Attachment

Re: pg_dumpall --exclude-database option

From
Michael Paquier
Date:
On Fri, Nov 30, 2018 at 04:26:41PM -0500, Andrew Dunstan wrote:
> On 11/18/18 1:41 PM, Andrew Dunstan wrote:
>> On 11/17/18 9:55 AM, Alvaro Herrera wrote:
>>> In the long run, I think we should add an option to processSQLNamePattern
>>> to use OR instead of AND, which would fix both this problem as well as
>>> pg_dump's.  I don't think that's important enough to stall this patch.

Agreed.  This patch is useful in itself.  This option would be nice to
have, and this routine interface would begin to grow too many boolean
switches to my taste so I'd rather use some flags instead.

The patch is doing its work, however I have spotted an issue in the
format of the dumps generated.  Each time an excluded database is
processed its set of SET queries (from _doSetFixedOutputState) as well
as the header "PostgreSQL database dump" gets generated.  I think that
this data should not show up.
--
Michael

Attachment

Re: pg_dumpall --exclude-database option

From
Andrew Dunstan
Date:
On 12/18/18 11:53 PM, Michael Paquier wrote:
> On Fri, Nov 30, 2018 at 04:26:41PM -0500, Andrew Dunstan wrote:
>> On 11/18/18 1:41 PM, Andrew Dunstan wrote:
>>> On 11/17/18 9:55 AM, Alvaro Herrera wrote:
>>>> In the long run, I think we should add an option to processSQLNamePattern
>>>> to use OR instead of AND, which would fix both this problem as well as
>>>> pg_dump's.  I don't think that's important enough to stall this patch.
> Agreed.  This patch is useful in itself.  This option would be nice to
> have, and this routine interface would begin to grow too many boolean
> switches to my taste so I'd rather use some flags instead.
>
> The patch is doing its work, however I have spotted an issue in the
> format of the dumps generated.  Each time an excluded database is
> processed its set of SET queries (from _doSetFixedOutputState) as well
> as the header "PostgreSQL database dump" gets generated.  I think that
> this data should not show up.


I'll take a look.


cheers


andrew


-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



Re: pg_dumpall --exclude-database option

From
Andrew Dunstan
Date:
On 12/19/18 3:55 PM, Andrew Dunstan wrote:
> On 12/18/18 11:53 PM, Michael Paquier wrote:
>> On Fri, Nov 30, 2018 at 04:26:41PM -0500, Andrew Dunstan wrote:
>>> On 11/18/18 1:41 PM, Andrew Dunstan wrote:
>>>> On 11/17/18 9:55 AM, Alvaro Herrera wrote:
>>>>> In the long run, I think we should add an option to processSQLNamePattern
>>>>> to use OR instead of AND, which would fix both this problem as well as
>>>>> pg_dump's.  I don't think that's important enough to stall this patch.
>> Agreed.  This patch is useful in itself.  This option would be nice to
>> have, and this routine interface would begin to grow too many boolean
>> switches to my taste so I'd rather use some flags instead.
>>
>> The patch is doing its work, however I have spotted an issue in the
>> format of the dumps generated.  Each time an excluded database is
>> processed its set of SET queries (from _doSetFixedOutputState) as well
>> as the header "PostgreSQL database dump" gets generated.  I think that
>> this data should not show up.
>
> I'll take a look.



I think you're mistaken. The following example shows this clearly -
there is nothing corresponding to the 20 excluded databases. What you're
referring to appears to be the statements that preceded the 'CREATE
DATABASE' statement. That's to be excpected.


cheers


andrew


    andrew@emma:inst (pg_dumpall--exclude)*$ for x in `seq 1 20` ; do
    bin/createdb ex$x; done
    andrew@emma:inst (pg_dumpall--exclude)*$ bin/createdb inc
    andrew@emma:inst (pg_dumpall--exclude)*$ bin/pg_dumpall
    --exclude-database "ex*"
    --
    -- PostgreSQL database cluster dump
    --

    SET default_transaction_read_only = off;

    SET client_encoding = 'UTF8';
    SET standard_conforming_strings = on;

    --
    -- Roles
    --

    CREATE ROLE andrew;
    ALTER ROLE andrew WITH SUPERUSER INHERIT CREATEROLE CREATEDB LOGIN
    REPLICATION BYPASSRLS;






    \connect template1

    --
    -- PostgreSQL database dump
    --

    -- Dumped from database version 12devel
    -- Dumped by pg_dump version 12devel

    SET statement_timeout = 0;
    SET lock_timeout = 0;
    SET idle_in_transaction_session_timeout = 0;
    SET client_encoding = 'UTF8';
    SET standard_conforming_strings = on;
    SELECT pg_catalog.set_config('search_path', '', false);
    SET check_function_bodies = false;
    SET client_min_messages = warning;
    SET row_security = off;

    --
    -- PostgreSQL database dump complete
    --

    --
    -- PostgreSQL database dump
    --

    -- Dumped from database version 12devel
    -- Dumped by pg_dump version 12devel

    SET statement_timeout = 0;
    SET lock_timeout = 0;
    SET idle_in_transaction_session_timeout = 0;
    SET client_encoding = 'UTF8';
    SET standard_conforming_strings = on;
    SELECT pg_catalog.set_config('search_path', '', false);
    SET check_function_bodies = false;
    SET client_min_messages = warning;
    SET row_security = off;

    --
    -- Name: inc; Type: DATABASE; Schema: -; Owner: andrew
    --

    CREATE DATABASE inc WITH TEMPLATE = template0 ENCODING = 'UTF8'
    LC_COLLATE = 'en_US.UTF-8' LC_CTYPE = 'en_US.UTF-8';


    ALTER DATABASE inc OWNER TO andrew;

    \connect inc

    SET statement_timeout = 0;
    SET lock_timeout = 0;
    SET idle_in_transaction_session_timeout = 0;
    SET client_encoding = 'UTF8';
    SET standard_conforming_strings = on;
    SELECT pg_catalog.set_config('search_path', '', false);
    SET check_function_bodies = false;
    SET client_min_messages = warning;
    SET row_security = off;

    --
    -- PostgreSQL database dump complete
    --

    \connect postgres

    --
    -- PostgreSQL database dump
    --

    -- Dumped from database version 12devel
    -- Dumped by pg_dump version 12devel

    SET statement_timeout = 0;
    SET lock_timeout = 0;
    SET idle_in_transaction_session_timeout = 0;
    SET client_encoding = 'UTF8';
    SET standard_conforming_strings = on;
    SELECT pg_catalog.set_config('search_path', '', false);
    SET check_function_bodies = false;
    SET client_min_messages = warning;
    SET row_security = off;

    --
    -- PostgreSQL database dump complete
    --

    --
    -- PostgreSQL database cluster dump complete
    --
     


-- 

Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



Re: pg_dumpall --exclude-database option

From
Michael Paquier
Date:
On Mon, Dec 24, 2018 at 02:46:48PM -0500, Andrew Dunstan wrote:
> I think you're mistaken. The following example shows this clearly -
> there is nothing corresponding to the 20 excluded databases. What you're
> referring to appears to be the statements that preceded the 'CREATE
> DATABASE' statement. That's to be excpected.

I would have believed that excluding a database removes a full section
from "PostgreSQL database dump" to "PostgreSQL database dump
complete", and not only a portion of it.  Sorry for sounding
nit-picky.
--
Michael

Attachment

Re: pg_dumpall --exclude-database option

From
Fabien COELHO
Date:
Hello Andrew,

> Rebased and updated patch attached.

Here is a review of v5, sorry for the delay.

Patch applies cleanly, compiles, "make check" is ok.

I do not see Michaël's issue, and do not see how it could be so, for me 
the whole database-specific section generated by the underlying "pg_dump" 
call is removed, as expected.

All is well for me, I turned the patch as ready.


While poking around the dump output, I noticed some unrelated points:

* Command "pg_dump" could tell which database is dumped in the output at 
the start of the section, eg:

   --
   -- PostgreSQL database "foo" dump
   --

Or "pg_dumpall" could issue a comment line in the output telling which 
database is being considered.

* The database dumps should have an introductory comment, like there is 
one for roles, eg:

   --
   -- Databases
   --

* On extensions, the dump creates both the extension and the extension 
comment. However, ISTM that the extension comment is already created by 
the extension, so this is redundant:

  --
  -- Name: pg_dirtyread; Type: EXTENSION; Schema: -; Owner:
  --
  CREATE EXTENSION IF NOT EXISTS pg_dirtyread WITH SCHEMA public;

  --
  -- Name: EXTENSION pg_dirtyread; Type: COMMENT; Schema: -; Owner:
  --
  COMMENT ON EXTENSION pg_dirtyread IS 'Read dead but unvacuumed rows from table';

Maybe it should notice that the comment belongs to the extension and need 
not be updated?

-- 
Fabien.

Re: pg_dumpall --exclude-database option

From
Michael Paquier
Date:
On Tue, Dec 25, 2018 at 09:36:05AM +0100, Fabien COELHO wrote:
> I do not see Michaël's issue, and do not see how it could be so, for me the
> whole database-specific section generated by the underlying "pg_dump" call
> is removed, as expected.
>
> All is well for me, I turned the patch as ready.

Sorry for the noise.  I have been double-checking what I said
previously and I am in the wrong.

>   --
>   -- PostgreSQL database "foo" dump
>   --
>
> Or "pg_dumpall" could issue a comment line in the output telling which
> database is being considered.

Mentioning which database dump has been completed in the end comment
could be additionally nice.
--
Michael

Attachment

Re: pg_dumpall --exclude-database option

From
Fabien COELHO
Date:
Bonjour Michaël,

>> I do not see Michaël's issue [...]
>
> Sorry for the noise.

No big deal!

>>   -- PostgreSQL database "foo" dump
>>
>> Or "pg_dumpall" could issue a comment line in the output telling which
>> database is being considered.
>
> Mentioning which database dump has been completed in the end comment
> could be additionally nice.

Indeed, it should be consistent.

Joyeuses fêtes !

-- 
Fabien.

Re: pg_dumpall --exclude-database option

From
Michael Paquier
Date:
On Tue, Dec 25, 2018 at 10:32:34AM +0100, Fabien COELHO wrote:
> Joyeuses fêtes !

Merci.  You too Happy New Year and Merry christmas.  (Sentence valid
for all folks reading this email, as well as folks not reading it).
--
Michael

Attachment

Re: pg_dumpall --exclude-database option

From
Andrew Dunstan
Date:
On 12/25/18 3:36 AM, Fabien COELHO wrote:
>
> Hello Andrew,
>
>> Rebased and updated patch attached.
>
> Here is a review of v5, sorry for the delay.
>
> Patch applies cleanly, compiles, "make check" is ok.
>
> I do not see Michaël's issue, and do not see how it could be so, for
> me the whole database-specific section generated by the underlying
> "pg_dump" call is removed, as expected.
>
> All is well for me, I turned the patch as ready.


OK, thanks.


>
>
> While poking around the dump output, I noticed some unrelated points:
>
> * Command "pg_dump" could tell which database is dumped in the output
> at the start of the section, eg:
>
>   --
>   -- PostgreSQL database "foo" dump
>   --
>
> Or "pg_dumpall" could issue a comment line in the output telling which
> database is being considered.
>
> * The database dumps should have an introductory comment, like there
> is one for roles, eg:
>
>   --
>   -- Databases
>   --
>

I agree these are unrelated but would be nice to have. Probably having
pg_dumpall do it would be better. Do you want to do a patch for that?



> * On extensions, the dump creates both the extension and the extension
> comment. However, ISTM that the extension comment is already created
> by the extension, so this is redundant:
>
>  --
>  -- Name: pg_dirtyread; Type: EXTENSION; Schema: -; Owner:
>  --
>  CREATE EXTENSION IF NOT EXISTS pg_dirtyread WITH SCHEMA public;
>
>  --
>  -- Name: EXTENSION pg_dirtyread; Type: COMMENT; Schema: -; Owner:
>  --
>  COMMENT ON EXTENSION pg_dirtyread IS 'Read dead but unvacuumed rows
> from table';
>
> Maybe it should notice that the comment belongs to the extension and
> need not be updated?



What if the owner had updated the comment after installing the extension?


cheers


andrew


-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



Re: pg_dumpall --exclude-database option

From
Fabien COELHO
Date:
Hello,

>> While poking around the dump output, I noticed some unrelated points:
>>
>> * Command "pg_dump" could tell which database is dumped in the output
>> Or "pg_dumpall" could issue a comment line in the output telling which
>> database is being considered.
>>
>> * The database dumps should have an introductory comment, like there
>> is one for roles
>
> I agree these are unrelated but would be nice to have. Probably having
> pg_dumpall do it would be better. Do you want to do a patch for that?

I do not "want" to do a patch for that:-) Anyway, a small patch is 
attached which adds comments to pg_dumpall output sections.

>> * On extensions, the dump creates both the extension and the extension
>> comment. However, ISTM that the extension comment is already created
>> by the extension, so this is redundant:

>> Maybe it should notice that the comment belongs to the extension and
>> need not be updated?
>
> What if the owner had updated the comment after installing the extension?

Hmmm… This point could apply to anything related to an extension, which 
could be altered by the owner in any way…

-- 
Fabien.
Attachment

Re: pg_dumpall --exclude-database option

From
Michael Paquier
Date:
On Thu, Dec 27, 2018 at 10:55:43PM +0100, Fabien COELHO wrote:
> I do not "want" to do a patch for that:-) Anyway, a small patch is attached
> which adds comments to pg_dumpall output sections.

Patch has been moved to next CF with the same status, ready for
committer.  Andrew, are you planning to look at it?
--
Michael

Attachment