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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Re: [COMMITTERS] pgsql: Adjust things so that the query_string of a cached plan and the
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Re: [COMMITTERS] pgsql: Adjust things so that the query_string of a cached plan and the