Re: parallel restore - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: parallel restore
Date
Msg-id 49653CD4.8030805@dunslane.net
Whole thread Raw
In response to Re: parallel restore  ("Jaime Casanova" <jcasanov@systemguards.com.ec>)
Responses Re: parallel restore  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

Jaime Casanova wrote:
>  Anyway i tried to run with
> --truncate-before-load and got a message about that should be
> necessary to run TRUNCATE CASCADE instead.
>
>   

Actually, this raises an interesting point. It doesn't seem safe to 
truncate before loading unless we have just created the table earlier in 
the restore. If we did create the table then any FK constraints that 
depend on the table should not have been created yet, so there should be 
no danger of getting this message (and there should be on danger of our 
wiping out actual data - the whole point of this is not to clean the 
tables but to inhibit unnecessary WAL logging of data loads).

That means that it would be useless for a data one restore, which was 
apparently the context in which Jaime was trying to use it.

Now, we could decide that we always want to do a safe truncate in a 
parallel restore (i.e. if we have created the table in the same 
restore), even if archive_mode is on. Then this switch would be 
redundant, and we might avoid some confusion. I'm inclined to do that 
right now. In that case we could leave for consideration for 8.5 a 
switch providing for a TRUNCATE CASCADE on tables before loading them.

Thoughts?

cheers

andrew


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Adjust things so that the query_string of a cached plan and the
Next
From: Tom Lane
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Adjust things so that the query_string of a cached plan and the