| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
| Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: no XLOG during COPY? |
| Date: | 2008-09-15 12:09:45 |
| Message-ID: | 48CE5089.2020800@dunslane.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gregory Stark | 2008-09-15 12:13:04 | Re: Transaction Snapshots and Hot Standby |
| Previous Message | Heikki Linnakangas | 2008-09-15 11:52:11 | Re: Review Report: propose to include 3 new functions into intarray and intagg |