Re: parallel restore
От | Andrew Dunstan |
---|---|
Тема | Re: parallel restore |
Дата | |
Msg-id | 49653CD4.8030805@dunslane.net обсуждение исходный текст |
Ответ на | Re: parallel restore ("Jaime Casanova" <jcasanov@systemguards.com.ec>) |
Ответы |
Re: parallel restore
|
Список | 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 по дате отправления: