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: | Raw Message | Whole Thread | 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 |