Simon Riggs wrote:
On Thu, 2008-09-11 at 15:25 -0400, Andrew Dunstan wrote:
Great, thanks (and also to Guillaume).
It looks to me like the simple way around this issue would be to provide
an option to have pg_restore emit:
begin; truncate foo; copy foo ... commit;
The truncate will be trivial as there won't be any data or indexes at
that stage anyway.
Not sure which stage you're talking about. If this is a parallel restore
and you are running a create in one session and a load in another, then
ISTM you have no way of knowing that for certain.
Er, who doesn't know what for certain, exactly? pg_restore will
certainly know that it has created the table in another session and can
thus safely truncate the table in the same transaction as the data load.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
