Re: [GENERAL] Move rows from one database to other
От | Thomas Güttler |
---|---|
Тема | Re: [GENERAL] Move rows from one database to other |
Дата | |
Msg-id | 6cea6503-84a4-e85b-f5f7-1fcf07907425@thomas-guettler.de обсуждение исходный текст |
Ответ на | Re: [GENERAL] Move rows from one database to other (Adrian Klaver <adrian.klaver@aklaver.com>) |
Ответы |
Re: [GENERAL] Move rows from one database to other
|
Список | 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/
В списке pgsql-general по дате отправления: