From: | Thomas Güttler <guettliml(at)thomas-guettler(dot)de> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Move rows from one database to other |
Date: | 2017-02-23 15:16:32 |
Message-ID: | 6cea6503-84a4-e85b-f5f7-1fcf07907425@thomas-guettler.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Am 22.02.2017 um 16:00 schrieb Adrian Klaver:
> On 02/22/2017 04:51 AM, Thomas Güttler wrote:
>>>> I have other concerns: atomar transaction. Movement should happen
>>>> completely or not all.
>>>> I don't think you can do this reliable (atomic transaction) with
>>>> "copy table_name".
>>>
>>> You can if you wrap it in a transaction:
>>
>> I want to **move** the data. The data should get deleted on the
>> satellite after transfer.
>
> Well the replication suggestion is out.
>
>>
>> I don't know how to delete the data which was copied, since inserts can
>> happen during the copy statement.
>
> However you end up doing this I think you will probably need some sort of flag on the rows on the satellites. It could
> be a timestamp field of when the rows where inserted on the satellite or a boolean field(copied). First instinct is to
> use an insert timestamp and a tracking table that stores the last timestamp used to move rows, where the timestamp is
> only written on a successful transfer. To improve the chances of successful transfer more smaller transfer batches
> rather then larger transfers.
I really need a solid solution.
You said "... improve the chances of successful transfer ...". This makes me nervous.
Delays are no problems, but data loss or duplication is.
Regards,
Thomas
--
Thomas Guettler http://www.thomas-guettler.de/
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Klaver | 2017-02-23 15:21:38 | Re: Foreign key references a unique index instead of a primary key |
Previous Message | Melvin Davidson | 2017-02-23 14:57:58 | Re: ShmemAlloc maximum size |