Re: logical changeset generation v3 - comparison to Postgres-R change set format
В списке pgsql-hackers по дате отправления:
| От | Markus Wanner |
|---|---|
| Тема | Re: logical changeset generation v3 - comparison to Postgres-R change set format |
| Дата | |
| Msg-id | 50A7CC53.6060001@bluegap.ch обсуждение исходный текст |
| Ответ на | Re: logical changeset generation v3 - comparison to Postgres-R change set format (Hannu Krosing <hannu@2ndQuadrant.com>) |
| Список | pgsql-hackers |
Hannu, On 11/17/2012 03:40 PM, Hannu Krosing wrote: > On 11/17/2012 03:00 PM, Markus Wanner wrote: >> On 11/17/2012 02:30 PM, Hannu Krosing wrote: >>> Is it possible to replicate UPDATEs and DELETEs without a primary key in >>> PostgreSQL-R >> No. There must be some way to logically identify the tuple. > It can be done as selecting on _all_ attributes and updating/deleting > just the first matching row > > create cursor ... > select from t ... where t.* = (....) > fetch one ... > delete where current of ... That doesn't sound like it could possibly work for Postgres-R. At least not when there can be multiple rows with all the same attributes, i.e. without a unique key constraint over all columns. Otherwise, some nodes could detect two concurrent UPDATES as a conflict, while other nodes select different rows and don't handle it as a conflict. Regards Markus Wanner
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера