Re: pg_dump'ed file contains "DROP DATABASE" - Mailing list pgsql-general

From pf@pfortin.com
Subject Re: pg_dump'ed file contains "DROP DATABASE"
Date
Msg-id 20230220222250.6b0df32c@pfortin.com
Whole thread Raw
In response to Re: pg_dump'ed file contains "DROP DATABASE"  (Adrian Klaver <adrian.klaver@aklaver.com>)
Responses Re: pg_dump'ed file contains "DROP DATABASE"  (Adrian Klaver <adrian.klaver@aklaver.com>)
List pgsql-general
On Mon, 20 Feb 2023 15:24:23 -0800 Adrian Klaver wrote:

>On 2/20/23 11:36, pf@pfortin.com wrote:
>> On Mon, 20 Feb 2023 11:06:34 -0800 Adrian Klaver wrote:
>>   
>>> On 2/20/23 10:27, pf@pfortin.com wrote:  
>>>> [Still a newbie; but learning fast...]
>>>>
>>>> Hi,  
>
>> 
>> Notwithstanding the man page, my take is that the DROP DATABASE statement
>> needs to be eliminated at pg_dump creation by pgAdmin4.  Taking this to
>> that mailing list.  
>
>It just dawned on me you might be doing all of this through the 
>pgAdmin4 GUI.

Sorry for any confusion...  I get it now...

A team member uses pgAdmin4 to load separate table(s) into his DB; then
creates dump files (one per table) of those _individual_ tables which are
uploaded to me. 

I maintain a complete set of tables in my DB. pgAdmin4 is never used
here; the restore is done with a simple bash script which inserts the
dbname and dumpfile name into the command. Those restore tables should
only be created with DROP DATABASE _off_.

All that should happen with my DB is to add these tables (99.9% of the
time, they are totally new to me).  

A DROP DATABASE from the one-table per dumpfile creator is UNwanted.

Looks like I really did dodge a bullet...  

>Again the default is to not include those options.

Glad to know pgAdmin4 has those switches.

Thanks again!!

>> 
>> Thanks Tom & Adrian!
>>   
>>>> Was my 134 table[1] myname DB saved because it was open?  
>> 
>> Tom:  Yup.
>>   
>>>> If the dump file
>>>> contains the above statements, how can I be absolutely certain I won't
>>>> lose the DB?  
>> 
>> Tom:
>> Reading the manual is advisable.  --create --clean specifies exactly
>> that the target database is to be dropped and recreated.
>> 
>>             regards, tom lane
>>   
>>>> I'm obviously quite paranoid now...  
>>>
>>> You will lose the database if you do as the docs specify for -C:
>>>
>>> "
>>> -C
>>>
>>> ...
>>>
>>> When this option is used, the database named with -d is used only to
>>> issue the initial DROP DATABASE and CREATE DATABASE commands. All data
>>> is restored into the database name that appears in the archive.
>>> "
>>>
>>>
>>> It will then be recreated with whatever information is in "dumpfile". If
>>> that is the same data or new data you want then you are fine. Otherwise
>>> you will need to be more specific about what you are trying to achieve.
>>>
>>>  
>>>>
>>>> [1] 3 types of tables:  ~40%=8.5M rows; ~40%=33M rows; ~20%=varying sizes
>>>>
>>>> Thanks,
>>>> Pierre
>>>>
>>>>      
>>>  
>> 
>>   
>



pgsql-general by date:

Previous
From: Bryn Llewellyn
Date:
Subject: Re: Thanks! Re: Who adds the "start transaction" and "commit" to the intended SQL statement in "autocommit" mode?
Next
From: Adrian Klaver
Date:
Subject: Re: pg_dump'ed file contains "DROP DATABASE"